RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)

[Leo Sutic]

> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> 
> Hi again, answer inline:
> 
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > However if you recall back to our original discussions on 
> > ComponentManager vs 
> > ComponentSelector vs NamedComponentManager. I didn't really like 
> > NamedComponentManager or ComponentSelector and tried to stop it 
> > but gave up - 
> > it was 3 vs 1 and even I get bored of arguing ... well on very 
> > rare occasions 
> > ;)
> 
> I also see no need for the ComponentSelector as a main component
> interface. I think it is even a bit confusing. It should just be
> an "implementation detail".
> 
> I also like much more the idea of having _some_ unique key that
> we probably should avoid calling Role. Maybe it should even be
> just an java.lang.Object key. 

I tried non-string roles in my C++ port of Avalon and the results
were less than optimal. The reason is that roles are one of those
attributes that are configured by the end user of the system - 
they appear in the XML configuration files that maps roles to 
component implementation classes.

If we had non-string roles, configuration would be much harder,
I'm afraid.

For the component selector, this is not a problem - we can have 
non-string hints, as the selector "knows" what type to expect.
 
/LS


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>