Re: [picocontainer-dev] annotations and comments on Pico2

On May 20, 2007, at 3:45 PM, Erik Putrycz wrote:

>
>
> Paul Hammant wrote:
>>         MutablePicoContainer mpc = new PicoBuilder().withCaching 
>> ().withHiddenImplementations().withSetterInjection().build(); //  
>> this one is working now
>>         MutablePicoContainer mpc = new PicoBuilder 
>> ().cachedInstances().hideImplementations().forSetterInjection 
>> ().build();
>>         MutablePicoContainer mpc = new PicoBuilder().caching 
>> ().hidden().forSDI().build();
>>         MutablePicoContainer mpc = new PicoBuilder().allSingletons 
>> ().hidden().forSDI().build();
>>
>>         MutablePicoContainer mpc = new PicoBuilder 
>> ().cachedInstances().hideImplementations().build(); // will do CDI  
>> implicitly & also working now
>>
>> At the moment, the order is important.  I'm sure that could be  
>> fixed though.
> The problem of this builder is that it won't be extensible for  
> other pico modules. Otherwise, I think it is a step in the right  
> direction.

Well I thought of a PicoBuilder in gems that extended (or delegates  
to) the one in core, and a NanoBuilder in nano that reimplemented it  
all (wraps) for NanoContainer as opposed to MutablePicoContainer.

As easily, PicoBuild could have methods of :-

    PicoBuilder withComponentAdapterFactory(Class cafClass);
    PicoBuilder withComponentAdapterFactory(ComponentAdapterFactory  
caf); // implicitly an end-point, unless we change DecoratingCAF to  
have a setDelegate(CAF caf) method.

> And something could be done for the order. Lets say you use the  
> ComponentCharacteristic for the builder:
> MutablePicoContainer mpc = new PicoBuilder().with(SDI).with 
> (Cached).build();

you could as easily do the following :-)

     MutablePicoContainer mpc = new PicoBuilder().with(SDI,  
CACHED).build();

> Where SDI and Cached are ComponentCharacteristic.
> Each component characteristic could implement something like
>  Class<? extends CompenentAdapterFactory> before();
>  Class<? extends CompenentAdapterFactory> after();

interesting...

> This way the builder makes a list of CAFs classes and can order  
> them to some extend.

Yup I've thought lots of the ordering:

Goal: as CAFs are added, they find their place in the list.  I've  
added InstantiationComponentAdapterFactory as a marker to signify an  
an end-point. It could be redundant though as everything that is not  
one of these is a DecoratingCAF.  How to order the DecoratingCAF  
derivatives though.  Clearly Caching needs to be at the front of the  
list if needed.  JMX, AOP etc need to be in the middle.



- Paul