avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Mon, 17 Jun 2002 09:57:56 GMT
On Mon, 2002-06-17 at 11:16, Nicola Ken Barozzi wrote:
> 
> Leo Simons wrote:
> >>>IOW:
> >>>making the 2-d to 1-d mapping part of the caller instead of the callee
> >>>simplifies the use of the callee where there is only 1-d.
> >>
> >>C'mon, what do we have java method overloading for? Berin proposed to
> >>have both
> >>
> >> lookup(role)
> >>
> >>and 
> >>
> >> lookup(role,hint);
> >>
> >>if you don't have any hint to pass, don't.
> > 
> > 
> > the thing with the CM interface is that every container that wants to be
> > useful will have to provide a good implementation. The implementation is
> > simpler (faster?) if you don't have to provide a lookup(role,hint)
> > function. My natural reaction was to declare the method optional (with
> > an UnsupportedOperationException option), but it was correctly pointed
> > out that this is not very good as you won't know that the framework is
> > exactly the same everywhere.
> > 
> > This is not an issue if the hint is truly an optional part of the lookup
> > 
> > // impl:
> > Object lookup(String role, Object hint)
> > { return lookup(role) };
> 
> 
> Ok, let's make this clear:
> 
> role+hint is *not* a simple way of declaring role="base+hint"
> 
> Role: what do do
> Hint: *how* to do it
> 
> Specifying a role, I just need something to be done, giving a hint I 
> also narrow the focus on a specific "way" of doing it.

I wasn't indicating otherwise; in fact, I wasn't indicating something
like that at all. If we clearly define a "hint" as a hint, ie safe to
ignore, that's cool. If we don't, there's less chance for compromise.

> Please reread my mails on this subject, and comment on those, especially 
> the last one with the SSLConection example.

you talk of "subroles". Subroles should be defined as a "part of" the
role.

ie:

Role: what to do
Hint: suggest how to do it

Subrole: just part of what to do, so part of role. Semantics up to
application.

> Hints are not part of the role IMO, they have different semantics.
> 
> This is why the methid needs to be there, although containers can decide 
>    to ignore the hint (they could also ignore the role btw, but makes 
> them ever less useful).

but they wouldn't pass "100% pure avalon" testing, whereas they would if
they ignore the hint.

options:
1 - don't allow for hints
2 - allow for hints, but also allow for them to be ignored
3 - require support for an object part in the CM lookup (where "hint is
an improper term as it is not optional)
4 - create a Role class/object that also has support for hints

I'm okay with 1 & 2.

- Leo



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


Mime
View raw message