> but imagine you write:
> sm.lookup( org.hedhman.niclas.sports.FootballLocator.class );
> (I left out the key for this example)
I did a grep of the entire [EMAIL PROTECTED] mailing list archives. As far as I
can see, there has always been a lot of discussion of
lookup(aClassDescriptor) in various forms, but only one proposal to pass
both the expected/desired interface, and a key describing which of possibly
multiple such objects is desired:
The reason I have advocated passing the return class as a
parameter of the lookup/get call,
e.g., T t = (T) myContext.get(myKey, T.class)
is that the context can verify the type of object that the
caller is expecting. If we added a suitable throws clause
to that get method signature, we force the caller to prepare
for the exception.
That was in November, 2002.
> > Merlin will ensure that the returned type in the above is a
> > FootballLocator and nothing else - guaranteed.
> Yes, Merlin, but I'm talking about framework :)
In other words, why not use lookup(which-object, what-type)? Good question.
> So, the first step we could take now, is to agree that this approach
> "locate(Football.class)" is more elegant than
> "lookup('org.hedhman.niclas.sports.Football')".
I need to point out that the first of the two can be very important in some
class loading environments. It ensures that the class is the one from the
client's context, which may not be the same as the container's.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
