avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] New Lookup mechanism
Date Mon, 12 Apr 2004 09:50:52 GMT
Stephen McConnell wrote:
Thanks Stephen for the info!

> > 
> > MyComponent c = (MyComponent)this.serviceManager.lookup( 
> > MyService.ROLE + '/' + hint );
> > 
> > There is never a lookup that uses some custom role name, like 
> > lookup("my-parser"); I think such lookups with custom role names 
> > should not be used anyway as they are way too error-prone.
> It is only error prone if the lookup key is not scoped to the 
> component implementation - for example in any merlin 
> component a key is simply a convenience factor local to the 
> implementation.  The thing I think your getting at is when a 
> string is passed to lookup who's semantics are relative to a 
> configuration - which means that the component is tied to a 
> particular deployment scenario - which is out and out bad.
Yes, exactly.

> > And even worse, ECM has the ugly concept of Selectors, so you first 
> > lookup a selector using MyService.ROLE+"Selector" and then the 
> > component from the selector using the hint. With the following 
> > semantics you combine the two in one interface.
> > 
> > Now, what do you think of using an easier solution:
> > public interface Locator {
> >     Object lookup(Class clazz, String hint); // or Object hint }
> I *hate* the "hint" terminology.  In English - hint means 
> something I can use or ignore.  If the string is a key - then 
> call it a key - but beyond this - semantics are required.

Agreed: key is a better word (Don't know why the term hint has been
for this years ago).

> <SNIP/>
> Given validation of the above - with complete specification 
> of a generic set of semantics of allowable map keys and 
> values and the corresponding selection criteria/semantics - 
> then you may have a framework candidate.

Hmm, I don't think that we have to do it that complicated.
Look at the current contracts of the framework: we have
service manager and service selector which is in combination
a rather ugly approach. So, my suggestion is just to 
combine those two in a much nicer way.


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

View raw message