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

Paul,

Thanks for your answer and I'm glad you brought a story with a *real* 
use case. I start to understand much better the philosophy of pico here.
My philosophy here is different though... For having done lot of work 
with hibernate, IMO the POJO part is a very small part of the big 
picture if you look at the work involved to switch from one framework to 
another. Same for containers, I don't believe so much in switching 
containers (I know the idea sounds good theorically) and I personally 
don't really care about lock-ins. Even if the container invades your 
code with interfaces and annotations, these are not the most difficult 
to take care usually... what is the real lock in is in my experience 
/the configuration/. Changing interfaces, refactoring some methods out, 
that can be all almost fully automated these days. But the hell lies in 
the customization, and configuration. I'd be quite surprised that in 
your example of moving from hibernate to batis or the other way, you 
would really just spend time removing the hibernate dependencies. In my 
experience, the real hard work is to get the collections, caching, 
activation depth, cascading behavior and other hell like that working. 
And let me bet that the POJO part doesn't do much about this stuff.

To take your example of the lifecycle interface, I do personally really 
like the interface. It is one of the reasons I moved all my code to pico.
To come back to the possible scenario that you need to change the 
container framework:
- first, you'll need to find something with the same semantics on the 
lifecycle - I think that is the most difficult part, your other 
container may have a different concept of start and stop and that is 
much more than just an interface dependency - ;
- and then change the interface to something else or remove it; and that 
can be done easily with some search replace + refactoring.
Whatever dependency you'll have on this interface, this won't be the 
most difficult.

In the end, it seems to me that this independence concepts makes an end 
user life more difficult and also cuts on other possible functionality. 
My philosophy is to do whatever is necessary to make your important code 
easy to read, test and maintain - even with the price of introducing 
dependencies. I'd be glad to discuss other scenarios. It is IMO more 
constructive to discuss use cases rather than concepts.

I have something to suggest for the pico configuration, I'll get back to 
you on that. I really like the
   pico.addComponent(Foo.class, FooImpl.class).with(HIDING);
   pico.addComponent(Bar.class, BarImpl.class).as(SINGLETON);
:-)

I won't go up to suggesting you to drink more  :-P but I think this goes 
in a good direction.

Erik.