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

 
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.

________________________________
	- 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.

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:

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.

- Jörg

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

    http://xircles.codehaus.org/manage_email