You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/06/22 10:04:15 UTC
Nano&Pico-Container
http://nanocontainer.codehaus.org/team-list.html
http://www.picocontainer.org/team-list.html
Now I know what Paul has been doing! :-)
What do you guys think about the Type1,2,3 Container explanation?
I don't buy it ;-P
http://www.picocontainer.org/introduction.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Nano&Pico-Container
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> http://nanocontainer.codehaus.org/team-list.html
> http://www.picocontainer.org/team-list.html
>
> Now I know what Paul has been doing! :-)
>
> What do you guys think about the Type1,2,3 Container explanation?
> I don't buy it ;-P
>
> http://www.picocontainer.org/introduction.html
>
The site you referenced presents an argument that there are 3 types of
IOC. It continues to provide examples. I would argue that none of the
examples represent types of IOC. In fact I would suggest that this is
presenting some historical information on the subject of "mechanisms"
for dependency declaration.
I would agree that there are different mechanisms that can be chosen for
a component to declare dependencies.
Approach 1: using meta information
- via packaged meta-info
Approach 2: using javadoc tags
- combined with a preprocessor to
generate the packaged meta-info
- i.e. is simply a layer above (1)
Approach 3: using the constructor signature
- class sequence corresponds to typed dependencies with roles
- role corresponds to ordered position of a type in the constructor
So at the end of the day you end up considering the approach to
dependency declaration and weighing expressiveness with simplicity. For
lightweight components, the introspection approach has benefits in that
you gain compile time checking (at the expense of tighter coupling).
However, this comes at a price: you loose the benefits of optional
dependencies (although this could be addressed by allowed multiple
constructor signatures), you loose the ability to control service
export, you loose certain benefits or orderly lifecycle phase
management, and you loose the ability to declare lifestyle.
Now - an interesting question - is the constructor approach incompatible
with the Avalon approach. My conclusion is that it is not. One could
consider the automatic assembly of objects based on a Constructor as
part of a standard component contract.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Nano&Pico-Container
Posted by Peter Royal <pr...@apache.org>.
On Sunday, June 22, 2003, at 08:08 AM, Leo Sutic wrote:
> [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?
That's essentially what XWork2 does, they have enabledXXX() methods
that are used to deliver dependencies.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Nano&Pico-Container
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi
>
> What do you guys think about the Type1,2,3 Container
> explanation? I don't buy it ;-P
Good:
+ Very easy to understand.
Bad:
+ 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
projects.
*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
IoC
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?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org