avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Nano&Pico-Container
Date Sun, 22 Jun 2003 12:08:10 GMT

> From: Nicola Ken Barozzi
> What do you guys think about the Type1,2,3 Container 
> explanation? I don't buy it ;-P


 + Very easy to understand.


 + By only using constructor parameters you do lose some
   way of specifying other dependency parameters besides
   the interface. Suppose you need two OutputStreams -
   standard and error, how is that specified?

That said, I think the loss of expressiveness in declaring
dependencies is more than offset by the easy-to-grasp-iness
of the concepts in terms of the number of problems that
can be solved with it. That is, suppose you had 100 projects
out there that could benefit from IoC componentized design:

With full-blast Avalon:

   + 100 of those can be solved in theory, BUT
   +  50 of those will fail in practice since it is just too
         darn hard to understand!

With PicoContainer/NanoContainer:

   +  75 of those can be solved in theory, BUT
   +   1 of those will fail in practice since it is just too
         darn hard to understand!

So the total success rate is higher, if one looks at all

*That* said - my project is one of the 25 that can't be solved
in theory with PicoContainer.

And *THAT* said - Paul, as the one that once wrote a "Micro" container,
are you just trying to think even smaller? :) Looking forward to
the Yoctocontainer. (http://physics.nist.gov/cuu/Units/prefixes.html)

Seriously though, ***I think it is a great idea***. Easily understood
with a minumum of dependencies and xml and what have you.

[RT]: Why not use reflection to set instance variables directly?

   public class Shop {
        * @dependency
       StockManager stockManager;

       public Shop() {

And have the container use reflection to set the stockManager field
as the component passes through the compose() stage?


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message