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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
