Re: [picocontainer-dev] comments on injection

Erik, a quick response for now (more full one later) :

PicoBuilder allows for a MPC class to be passed in as "Custom  
Container" already.  Also, DPC could well be final with -

> public class MagicLocatingPicoContainer extends  
> AbstractDelegatingMutablePicoContainer {
>
>   // ctors ..
>
>   public Object getComponent(Object key) {
>
>      Object inst = delegate.getComponent(key);
>
>      if (inst == null) {
>
>          delegate.addComponent(key);
>
>          return delegate.getComponent(key)
>
>      } else {
>
>         return inst;
>
>      }
>
>   }
>
> }

On Jun 6, 2007, at 10:13 AM, Putrycz, Erik wrote:

> Of course I have few comments J:
>
> 1) ok explicit registration is lost that is true, but I’m not sure  
> if the audit is always vital. This is IMO project dependent. With  
> this feature, it is possible to have almost no setup code for pico.  
> Also what I have in my code is a @NonInstanciable annotation on  
> classes that throws an exception if such component gets registered.
>
> 2) This would work using pico usual strategies and in this case,  
> wouldn’t pico just fail? I don’t think there is any solution to  
> this. The user would have to manually handle the registrations.
>
> 3) The simple implementation I provided relies on pico’s chain of  
> CF for figuring out the DI type. But the locator is the basic API  
> that would allow customizing this behavior.
>
>
> Also somehow I think it is too early to answer 2) and 3) because  
> this will totally depend on the use cases.
>
>
> I know that this is feasible by extending pico (I had that is my  
> code before) but that’s the whole goal of the locator. I don’t  
> think that extending pico is the best way to customize the  
> behavior… It is not elegant and complex with all the different  
> constructors and child containers… also as soon as you extend it,  
> you cannot use the builder anymore. If it was up to me I’d make the  
> defaultmutablecontainer final.
>
>
> Erik.
>
> From: Paul Hammant [mailto:[email protected]]
> Sent: June 6, 2007 0:59
> To: dev-qxt/[email protected]
> Subject: Re: [picocontainer-dev] comments on injection
>
>
> Erik
>
>
> I've thought about this since you penned it.
>
>
> Inversion of Control suggests that control is good ( in a certain  
> direction).  getComponent(..) returning instances for formerly  
> unregistered components is bad for mutiple reasons:
>
>
>   1) you've lost the explicit registration step, meaning the audit  
> of what's being used is not clear
>
>   2) there recursive nature of deps ( Apple needs Banana needs  
> Orange ) can not adequately tell which constructor to use.  Should  
> it aim at the simplest (no args) or the greediest as a strategy?
>
>   3) mixing of DI types.  if a Annotation DI Apple needs Banana or  
> Orange, should they be the same injection type? or same with a  
> fallback of CDI ?
>
>
> Finally,
>
>
> The whole thing is doable without ComponentLocator changes  :
>
>
> public class MagicLocatingPicoContainer extends DefaultPicoContainer {
>
>   // ctors ..
>
>   public Object getComponent(Object key) {
>
>      Object inst = super.getComponent(key);
>
>      if (inst == null) {
>
>          addComponent(key);
>
>          return super.getComponent(key)
>
>      } else {
>
>         return inst;
>
>      }
>
>   }
>
> }
>
>
> Thoughts?
>
>
> - Paul
>
>
>
> On Jun 1, 2007, at 1:46 PM, Putrycz, Erik wrote:
>
>
>
>
> Here is another expanded testcase and more doc.
>
>
> Erik.
>
> From: Paul Hammant [mailto:[email protected]]
> Sent: June 1, 2007 16:20
> To: dev-qxt/[email protected]
> Subject: Re: [picocontainer-dev] comments on injection
>
>
> Expand that a little more with testcode will ya Erik?
>
>
> -ph
>
>
> On Jun 1, 2007, at 11:21 AM, Putrycz, Erik wrote:
>
>
> My other (main) use case is injection…
>
> When I have
>
> @Inject
>
> private MyClass _myClass;
>
>
> If MyClass is not registered then it gets registered automatically  
> in Pico. With this feature, I hardly have any “initialization” code  
> in my projects. I just start my project by creating a container and  
> everything else gets wired automatically. I’m not sure how this  
> could work out with “getInstance”.
>
>
> Erik.
>
> From: Paul Hammant [mailto:[email protected]]
> Sent: June 1, 2007 13:27
> To: dev-qxt/[email protected]
> Subject: Re: [picocontainer-dev] comments on injection
>
>
> What other usecase is there Erik ?
>
>
> For the one you;ve given :-
>
>
> +          @Test
>
> +          public void testDynamicRegistration() {
>
> +                      MutablePicoContainer pico = new  
> DefaultPicoContainer();
>
> +                      ComponentLocator dynamicReg = new  
> DynamicRegistrationLocator();
>
> +                      pico.addLocator(dynamicReg);
>
> +                      LinkedList<String> list = pico.getComponent 
> (LinkedList.class);
>
> +                      assertNotNull(list);
>
> +          }
>
>
>
> I might prefer ..
>
>
> +          @Test
>
> +          public void testDynamicRegistration() {
>
> +                      MutablePicoContainer pico = new  
> DefaultPicoContainer();
>
> +                      LinkedList<String> list = pico.addComponent 
> (LinkedList.class).getInstance();  // getInstance() is new and  
> implicitly on the last component added ~  v easy to implement
>
> +                      assertNotNull(list);
>
> +          }
>
>
> I know you have a 'bigger' use of your way up your sleeve :-)
>
>
> - Paul
>
>
> On Jun 1, 2007, at 9:46 AM, Putrycz, Erik wrote:
>
>
> <Pico2-locator.patch>
>
>
>
>
> <Pico2-locator.patch>
>
> ---------------------------------------------------------------------
>
> To unsubscribe from this list please visit:
>
>
>     http://xircles.codehaus.org/manage_email
>
>
>