RE: [picocontainer-dev] comments on injection

Of course I have few comments :-):

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