Paulo:
I agree on the efficiency point, .. however the interface is
loosing something in terms of implicit clarity and potential for
consistent usage (it's starting to look more like hashtable
get/indexof/remove). I would prefer to move further towards an
interface that (a) expresses notions of service provision/
decommissioning more concretely and explicitly (i.e. closer to
yesterday), but (b) enhanced to address input from yourself,
Antti and Sylvain during the evening that touched on the
parallelism between lookup and hasXxxx. Thinking about the
parallelism issue for the last few hours as a result of those
comments leads me to the conclusion that non-parallel
lookup/hasXxxx effectively implies potentially unwarranted
implementation restrictions. A resolution could be the addition
of a supplementary hasXxxx method as shown below.
interface ServiceManager
{
Object lookup( final String role );
Object lookup( final String role, Map policy );
boolean hasService( final String role );
boolean hasService( final String role, Map policy ); <-- addition ?
void release( Object key );
}
The addition of hasXxxxx( key, policy ) ensures that your not going
on a blind date. The boolean result of the operation should
semantically be quite clear in that TRUE hasXxxxx response should
indicate that within reasonable operating conditions, the lookup
operation will not fail. It is then up to implementations to resolve
decisions concerning ability to honour a service availability
commitment (potentially in the context supplied policy).
What do you think?
Cheers, Steve.
> > ...but Map does allow potentially more efficient implementations.
>
> For efficiency:
>
> interface ServiceManager
> {
> Object lookup( Object key );
> boolean hasService( Object key );
> void release( Object key );
> }
>
> IMO this provides the most efficient basic implementation and
> maximum flexibility.
>
> Than you can specialize according to your needs.
>
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Antti Koivunen [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 13, 2002 10:04 PM
> > To: Avalon Developers List
> > Subject: Re: [VOTE] RE: ComponentManager interface
> >
> >
> >
> > Stephen McConnell wrote:
> > > I understand and support the concern re. mixing in the Parameter
> > > object. Personally I would prefer Map over Query. Here is my
> > > understanding of what the interface would look like (all method
> > > included) based on quasi "consensus" at this stage + your
> > > suggested replacement of Parameters with Map.
> > >
> > > interface ServiceManager
> > > {
> > > Object lookup( final String role );
> > > Object lookup( final String role, final Map attributes );
> > > boolean hasObject( final String role );
> > > void release( Object object );
> > > }
> > >
> > > Is this ok with everyone?
> >
> > I can't vote, but it looks fine to me. For what it's worth, Parameters
> > would allow us to define the needed component with a single
> string, e.g.
> > "com.mycompany.MyComponent:myParam=value,yourParam=42", but Map does
> > allow potentially more efficient implementations.
> >
> > (: Anrie ;)
> > --
> > Antti Koivunen | "Anrie" [un-ree] <[EMAIL PROTECTED]>
> > ---------------------------------------------------------
> > The song of life might not be a simple one,
> > but there's plenty of room for improvisation.
> > ---------------------------------------------------------
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
