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

Paul Hammant wrote:
> 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.
> 

The issue goes back to the early days when the static constructors with defaults were replaced with 
the "russian doll" model.  Now that we have the builder syntax, we should exploit it to the full
and impose a greater transparency.  Although, also via builder, we should still have an easy way to
do achieve the default behaviour.

> 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

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

Why poor?

>> 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 ?

I think the issue is a fail-fast approach or not to dependency resolution.

It would be good to know what all dependencies required by a given DI are resolvable and not have to 
  resolve them one-by-one.

Cheers



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

    http://xircles.codehaus.org/manage_email