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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
