[dev] Injector musings

[Michael M Slusarz]

1.) Is the eventual goal to remove all singleton methods from  
libraries?  To me, the answer would seem to be yes because if we  
eventually use getInstance()/createInstance() to reliably grab an  
instance, if that library in the future would need an outside  
dependency it would only be necessary to resolve this dependency by  
creating a binder interface in Core.

2.) How do you create an instance with an injector if that instance's  
constructor has varied arguments?  This seems to be a limitation of  
Horde_Injector... is this by design or simply because nobody has  
implemented it yet.

For example, Horde configuration needs to be decoupled from  
Horde_Mime_Viewer.  However, every Horde_Mime_Viewer instance does not  
need every single configuration option passed to it that might  
potentially be used by the drivers.  On the other hand, the drivers  
may create other Horde_Mime_Viewers internally that may need config  
options not needed by the original driver.

Regardless, it is very useful to keep the instance around since it  
might be used elsewhere in the code.  A better example of this might  
be IMP_Contents.  Once initialized, it may be used in various  
locations around the code that are not accessible to each other.  How  
does this work with injector usage?  Or is this the motivation to  
retain usage of singletons in this usage pattern?

3.) Configuration buried deep within core library functions is  
troublesome.  Example - Horde_Auth::setAuth(), which contains a call  
to Net_DNS_Resolver, which may potentially be configured via Horde's  
config file.  setAuth() is called from a variety of locations, and is  
also called internally by a variety of other library calls.  Passing  
the resolver object as a parameter isn't really doable and would be a  
giant step back in usability.  And it isn't possible to pass the  
resolver object to Horde_Auth since it is not setup to be OO for this  
kind of use.  Even if we convert to an OO-model, Horde_Auth is called  
from so many places that if we have to add additional parameters to  
10's or 100's of calls, this seems like a step back.

My solution was to set a static public member variable to a  
Net_DNS_Resolver object via the Horde_Registry.  It seems a bit  
hackish, but also seems like the cleanest/easiest way to decouple the  
configuration from the library.  Comments/concerns on this approach is  
much appreciated.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]