You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/11/24 10:30:26 UTC

Re: Avalon Container Framework

Berin Loritsch wrote:
> Jonathan Hawkes wrote:
<snip/>
> <snip type="implementation stuff"/>
 >
 >> What I AM advocating is simply the existence of a container
 >> framework.

lets call it 'containerkit'! <ducks/>

Seriously, lets not call it "container framework". Let us just build an 
extensible container, and hope its pieces are reused :D

> There are some pieces that are missing from your overview.

disagree! Jonathan is right on the mark with not specifying the missing 
pieces right away. Start small; incremental design :D

 > [Specification/Implementation of dependency resolution policy]

Actually, I believe there's only a few people who feel like customizing 
dependency resolution. Looking at all the existing implementations of 
IoC, none is really built for customizing the dependency resolution 
policy. Sure, its *possible*, but it is quite an uncommon usecase.

Furthermore, this is a usecase that will automatically be addressed by a 
good decomposition (as long as we consistently seperate api from policy, 
or consistently allow pluggable implementations).

 > [Metadata access]

Important question: what metadata are you talking about? I believe you 
are talking about the information the factory/adapter needs from the 
kernel/registry in order to fulfill its contract.

What kind of data is that?

I am strongly leaning towards making the contract between kernel and 
factory very minimal, placing most of the responsibility inside the 
factory. Coupled with a clean SPI, a usable abstract base and a pattern 
like Delegate, this allows for lots of reuse without requiring rocket 
science.

 > [Component configuration and container constants]
<snip/>
 > the "big" container can take care of getting all the components set
 > up.

eh? Why would you want to do that?

 > [Instrumentation]

all the AOP frameworks out there have Instrumentation as a standard 
example. It works well. The cool thing (and the bad thing) about AOP is 
that you can mix it in at any time in the design process. So again, I 
believe this is a topic best left for later.


Berin, what are you thinking about? A big container, a small container, 
a framework, a kernel, metadata? It doesn't compute.


cheers,


- LSD



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