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

Lots of good thoughts.

I'm working some on some related idea, albeit in a different style.  
It could well be that the idea is flawed, but take a look at for now..

     http://svn.picocontainer.codehaus.org/browse/picocontainer/java/ 
sandbox/baby-steps/pico2/container/src/test/org/picocontainer/ 
PicoBuilderTestCase.java


In not sure of the naming (as ever). Here are alternatives for the  
same idea ( Cached, Impl Hidden, and SDI only):

         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.

- Paul


On May 20, 2007, at 12:19 AM, Erik Putrycz wrote:

>
>> Thoughts?
> - Make ComponentCharacteristics a Java Enum instead of string  
> comparison, that would be more java 5 friendly. the way it is now,  
> it looks too much like a workaround.
> - I think a key principle in the API should be that the  
> characteristics would be extensible. The way it is now, you wire  
> into the CAs the characteristics. I would suggest doing the  
> opposite: the characteristics wire the CAs. So far to what I  
> understand, a CACHE characteristic won't be used unless the  
> CachingComponentAdapterFactory is in the pipeline.
> My suggestion would be that the ComponentCharacteristic implements  
> a method getComponentAdapterFactory(ComponentAdapterFactory  
> parent). If all the characteristics handling ends up in ifs in CAs,  
> I'm not sure how extensible this will be.
> I would even suggest an API to configure default:
> MutablePicoContainer pico = DefaultPicoContainer.buildContainer 
> ().with(NO_CACHE);
> The main objective is that the day someone wants to write an  
> extension, lets say thread local you could write something like:
> MutablePicoContainer container = new DefaultPicoContainer();
> container.as(ThreadLocal).addComponent(ThreadLocalComponent.class);
> without nothing else whereas with the current characteristics you  
> would have to write:
> MutablePicoContainer container = new DefaultPicoContainer(new  
> ThreadLocalComponentAdapterFactory());
> container.as(ThreadLocal).addComponent(ThreadLocalComponent.class);
> not to mention when you will have more extensions, you'll end up  
> with ugly contructors and the poor end user will have to figure out  
> the order.
>
> And more (un)popular suggestions:
> I think processing setters, getters and @Inject annotations is  
> really quite different from what CAs were originally about.
> CAs are like factories, they generate instances.
> But setters and annotation processing comes after and just do  
> something to an existing instance. And just a wild bet, there will  
> be more and more annotation processing in the future. With the  
> current CA model you are totally dependent on the order the CAs are  
> configured in with their constructor and that wont play too well  
> with many extensions at the same time (if everyone extends  
> DefaultComponentAdapter).
>
> Another thing: I think a pipeline model of CAFs in the container  
> would make the configuration much better than delegating CAFs.  
> Given how many classes extend DecoratingComponentAdapterFactory, it  
> would be possible to make something much cleaner by having a  
> specific interface for the pipelining CAFs (Hivemind has that as a  
> prime concept, and it is very powerful and clean) and cut on  
> inheritance, and dependence on constructors. Same could apply to CAs.
>
> Erik
>