Re: [picocontainer-dev] Builder confusion and cycles in annotation

Jörg,

On Jun 14, 2007, at 10:49 PM, Jörg Schaible wrote:

>
> Hi Erik + Paul,
>
> ________________________________
>
> 	From: Putrycz, Erik
> 	Sent: Thursday, June 14, 2007 8:57 PM
> 	Subject: [picocontainer-dev] Builder confusion and cycles in  
> annotation
> 	
>
> 	2 points:
>
> 	- The builder and default container are confusing: if you use the  
> builder, you get the caching by default even when you don't say  
> withCaching() because most contructors of picocontainer create the  
> caching adapter. Also having a NOCACHE characteristic + settings in  
> the builder is somehow redundant. I find the  
> componentcharacteristic system not elegant at all.
> ________________________________
>
> +1. I was never a friend of the default CAF within the DPC. A PC  
> should simply have one method registerCA and a user should use an  
> explicit builder instance to register the CAs. Look at all this  
> complicated code that try to create child PCs (especially in Nano)  
> with the same sematics as the parent.

I'm not sure there is a problem here. Awaiting Erik's response my  
last post.

>
> ________________________________
> 	- The current strategy of dealing with cycles is to throw an  
> exception when a cycle is found. However many cycles can be solved  
> when using only method and field injection. What I suggest (and  
> have done) is to track all the instances being injected and keep  
> going recursively until they are all done even when there are  
> cycles. A current limitation is that all relies on getComponent, so  
> I'm not sure there is a way to flush a cache in a CA after the root  
> getComponent is processed.
> ________________________________
>
> Please explain. I don't understand how the type of DI will prevent  
> cylces or how a cycle will not end-up in an endless recursion.  
> Additionally there's also the constraint that Pico will only create  
> an instance of a component if it is really needed.
>

+1

> The complete point is a bit different, if the algorithm (currently  
> implemented in the CICA) is changed. Currently it selects the ctor  
> with the most params and tests all the arguments ony by one if the  
> provided pico may be able to return an instance. This is IMHO  
> somewhat wrong. The CICA should request the PICO with all params of  
> a ctor at once ... more generic i.e. the Pico is requested by a CA  
> to resolve all its deps at once, somewhat like:
>

Its currently in two phases - "can resolve" a constructor, then  
"resolve" as the object.  I'm not sure what the problem is.  If it  
was instantiating everything thats dependent then discarding it so it  
can simply suggest "yes" to the "can resolve" question then it would  
be poor.

Maybe there's an optimization on the resolve that reduces the doing  
the same more than once scenario. Will play with that idea.

> boolean pico.canResolveDependencies(Object resolvedFor, Map<Class,  
> String> deps);
>
> The Map contains the necessary type of the component as key while  
> the String parameter is a hint that may be null (for CICA) or a  
> name (CICA with Paranamer, Field name, property name, ...). The  
> "resolvedFor" can be used for a Pico implementation that has a  
> meaning of real (basic/primitive) parameters that should be  
> assigned to a distinct component.

What the problem we're trying to solve though there ?
>

- Paul
---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email