avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Map and Array Dependencies
Date Tue, 01 Oct 2002 09:10:44 GMT
On Tue, 2002-10-01 at 10:26, Peter Donald wrote:
> Hi,
> I have just added support for complex dependencies in Phoenix so that they can 
> either be an array of services or a map of services. To declare an array you 
> just postfix it with "[]" and to declare a map you postfix it with "#" in 
> xinfo file. And then you can just access it via something like
> void service( ServiceManager sm )
> {
>   //An array of services
>   MyService[] services1 =
>    (MyService[])sm.lookup( MyService[].class.getName() );
>   //Same as above
>   MyService[] services2 =
>    (MyService[])sm.lookup( MyService.ROLE + "[]" );
>   //A unmodifiable Map of services
>   Map services3 =
>    (Map)sm.lookup( MyService.ROLE + "#" );
> }
> It seems to work well. However I don't really like the idea of postfixing the 
> service with "#" to indicate a map. I have thought about using "{}" instead 
> or maybe "<>" - Any preferences?

I like # best.

> Any other comments?

This adds additional semantic meaning to the lookup key, modifying the
sm contract. This makes your components (atm) phoenix-specific, it is
also the way to a dll-like-hell if we keep adding meaning to core
contracts that wasn't there before.

What if I have an application deployed in phoenix 4.0 that just happens
to postfix about half of its components with "#"? It will break in the
next release. Granted, what are the chances....but the thing with
contracts is you should be really strict about them.

We could do the whole yada-yada on this again....

I'm not going to throw a -1 at it because I don't really feel like
having to go over exactly the same discussions again. I feel like doing
so though.

Anyway, it makes me more sure that the only way to have avalon survive
is to define that the minimum contracts defined in avalon framework are
also the maximum ones........

All that said, it does seem like a nice idea that satisfies a particular
need. We just can't do it :S



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

View raw message