avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 10:38:56 GMT

Peter Donald wrote:
> On Tue, 3 Dec 2002 21:17, Adam Murdoch wrote:
>>Sure.  These are good examples of why everyone wins when there's a nice
>>match between what a resource means to a component, and how the resource is
>>delivered to the component.  If the component wants a logger, give it a
>>logger.  If the component wants config, give it config.  etc.  Maybe the
>>same resource is presented in different ways depending on how the component
>>asks for it.  Maybe not.  Component doesn't care.
>>But the examples don't really answer the question:  Why is it useful, when
>>a component asks for a resource of a particular type, to distinguish
>>between resources of that type that are provided by the container, and
>>resources of that type that are provided by other components?
> I don't really understand what you are getting at. If you are wanting to unify 
> the interface then this has already proposed - I actually created another 
> service API recently that looked something like
> interface Composable
> {
>   void compose( Locator locator ) throws LocatorException;
> }
> interface Contextualizable
> {
>   void contextualizable( Locator locator ) throws LocatorException;
> }
> interface Locator
> {
>   Object lookup( String key ) throws LocatorException;
>   boolean exists( String key );
> }
> If thats what you mean then I think I agree. It resulted in cleaner code.

The fact that Composable and Contextualizable have basically the same 
signature is an issue IMHO.

LogEnabled, Confisurable, et all were made indipendent, and each give a 
*different* thing (Logger, Configuration, etc).

Having two methods of getting Objects (because whatever we can say in 
Java they *are* Objects), causes confusion and concern overlap.

The Context is an interface with a method. Then we must use *that* 
method. Casting makes it simply another servicemanager, which really 
confuses, and makes boundaries very blurred.

> If you mean merging Contextualizable and Composable then I disagree. 

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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