> -----Original Message-----
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: den 10 januari 2002 16:37
> To: Avalon Developers List
> Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> Hi Berin and Leo,
>
>
> IMO any of those solutions cuts reusability and mix concerns.
I don't see how this is. If the CM interface can not be used to
lookup anything but components, then that is fine. If you need to
look up something else, define a new interface - XManager - and
use it to lookup Xs.
Now if you are talking about the ECM implementation, then that's
something else entirely.
> - Now look at the current situation where most tools are so happy
> just working with a String role and a String hint. The context
> object is much heavier to build, but on CPU and keystrokes!
> This makes those that just want the simple version to pay an
> extra cost because of the "complicated guys".
The time taken to lookup the component would have to be significant
compared to the time it takes to use it before it becomes a problem.
> On the other hand, we can have a ComponentManager that implements
> the above mentioned functionality accepting a separate indexing
> strategy and then wrap it according to our usage. One possible
> wrapper would just have the old style interface with:
> Object lookup( String role )
> {
> super.lookup(role);
> }
>
> Object lookup( String role, String hint );
> {
> super.lookup(new RoleAndHint(role, hint));
> }
>
> For the scripting guy just:
> Object lookup( String name )
> {
> super.lookup(name);
> }
>
> For the localized, "sessioned", complicated guy:
> =;o)
> Object lookup(String name, Context, ctx)
> {
> super.lookup(new NameAndCtx(name, ctx));
> }
>
> Sorry, but I do not understand why is the ComponentSelector
> necessary. You can always achieve the same with a composite key.
Yes, but...
> You can still use a ComponentSelector as an "implementation"
> detail if the indexing strategy is flexible enough.
>
> Obviously, the indexing strategy has to do with the algorithm
> used to build the key of the object and that will be domain
> specific. And the components for a given domain that need to
> access other components from the ComponentManager must know
> what indexing strategy is being used.
...and this is where your strategy fails. As long as we allow
Composable components, the component itself will be tied to
the domain (and indexing method) - as it must know how to look
up other components.
> Application domains can be completely different. I don't give
> a sh*t for Sockets and SocketPools as James will and James
> possibly does not need to name components as I do. Ant has
> probably some other indexing needs.
But can these needs not be solved without reworking the CM?
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
