avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 10:45:08 GMT
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.

If you mean merging Contextualizable and Composable then I disagree. 

-- 
Cheers,

Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham 


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


Mime
View raw message