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