Peter, thanks for the clarification.
How about instead of ROLE member having this idiom.
DataSourceComponent dataSource =
(DataSourceComponent)manager.lookup(DataSourceComponent.class.getName());
With ROLE the code would look like this
DataSourceComponent dataSource =
(DataSourceComponent)manager.lookup(DataSourceComponent.ROLE);
Not too much of a difference, but the former avoids adding an additional
constant to each interface . I think it would be good to avoid adding
things if the language can provide a nice way. Either way, it is sort of
philosophical and not too much of deal. As a user I would be happy either
way, but would prefer the former.
Harmeet
----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
Sent: Wednesday, May 16, 2001 10:19 PM
Subject: Re: [Proposal] Should we introduce a new idiom for Components?
> At 07:16 16/5/01 -0700, Harmeet Bedi wrote:
> >Why not change the lookup method to take an interface rather than a
string
> >as a parameter.
> >
> >So it would be
> >DataSourceComponent dataSource =
> > (DataSourceComponent)manager.lookup(DataSourceComponent.class);
> >
> >That way not only do you get the idiom without adding the 'ROLE' member,
but
> >also do a lookup for a role, and in Java one could argue Interface is
Role.
> >
> >What do you think ?
>
> That was discussed a while ago - there was two major problems with it.
>
> 1. Some interfaces serve multiple roles. ie Both spool and store can have
> the same interface but they have vastly different implementations. Now
> there are some components that will need access to both (ie the processor
> component that moves things from spool to store) which would not be
> possible if access via interface. This problem however could be gotten
around.
>
> 2. Classloader issues - it would considerably complicate classloader
issues
> for containers. Using strings means that ComponentManagers don't have to
> worry about all these things however using Class objects means that
several
> layers of complexity would have to be added and ordering in kernel
> operation. This can't be gotten around easily.
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
