Hi Leo,

> -----Original Message-----
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 11, 2002 8:46 PM
> 
> ...
>   
> > > > I also mentioned having a replaceable "indexing" strategy that 
> > > you might 
> > > > change for specific Domains. Go back a bit on this thread (or in the
> > > > [RT] Is Poolable Harmful?) and you will find it.
> > > 
> > > Yes, but if I understood you correctly (and looking below, I 
> > > did), you had 
> > > an indexing strategy that was CM-wide.
> > 
> > YES!
> > 
> > 
> > See this paragraph that follows?
> > 
> > > > However, I just want a CM wide "indexing" strategy, which on some 
> > > > implementations might even delegate some cases to... (tadaaaaaaa) 
> > > > ComponentSelectors.
> > > 
> > > By delegating this responsibility to CS, you allow components from
> > > different domains to exist in the same CM. If the whole CM has one
> > > strategy, then you can not do this.
> > 
> > Ok, I REPEAT:
> >   "...which on some implementations might even delegate some cases 
> >   to... (tadaaaaaaa) ComponentSelectors."
> 
> Which is a non-statement, since the component does not know anything
> about the component manager implementation.

Why not?
Why does putting a String and a Context instead of an Object transmit
more knowledge. 

It is all in what you do with it.

I could call lookup like this:
  c = cm.lookup("$#@))(sdjhfkjh");

Makes no sense and compiles with the 
   lookup(String role)
format.

 
> > > With two lookup methods: lookup(role) and 
> lookup(role,context), you can
> > > be certain that no matter what strategy is used, you will get back an
> > > interface of type role. 
> > 
> > WHY will you be so certain of that?
> 
> Because it is specified in the ComponentManager contract. If I lookup "X"
> I know I will get
> 
>  a) an object that is cast-able to X
>  or
>  b) a ComponentException
> 
> Tell me, Paulo, what would your contract for the ComponentManager 
> interface
> be? Assume that there is a component Aimpl that needs to lookup another 
> component implementing interface B.
> 
> We get:
> 
> class Aimpl {
>   void doStuff () {
>     ...
>     B b = (B) manager.lookup ( ???? What do I put here ???? );
>     ...
>   }
> }
> 
> Avalon contracts state that the role name == interface name, so 
> now I would
> look up (String) "B". What is your contract? What do I send to 
> the lookup method to
> get a B component *irrespective of the CM implementation*?
> 
> This is the "predictability" I talk about.

You can have exactly the same contract with the implementation I 
proposed. And you can even have others too, as I have.

And my contract is clear and works fine. It is just different.

The advantage of changing is that then other people can have 
different contracts and can keep them or not compatible with the 
Avalon contracts.


> > > With my proposal, you would also be certain that
> > > the context is interpreted in a predictable way, irrespective 
> of the CM
> > > implementation.
> > 
> > Why is my way unpredictable?
> > Is the Map interface unusable and unpredictable?
> 
> The Map interface in itself is not unpredictable and not unusable. 
> 
> But in this case, the code populating the map and the code fetching things
> from the map are separate and not even aware of each other. Thus 
> there must
> be an assigned meaning to the key values, and that meaning must be made 
> explicit in the contract.

Hum... just the same thing as any use of a Map!

 
> I have not seen you propose any such contract.

I am not proposing a contract. I am proposing that it can support
ALSO other contracts. 

MOST of those contracts would be compatible extensions of Avalon's 
contracts and would be able to reuse its components. Just like it 
happens with mine.

The Context parameter is just another way of extending the contracts.
And it is not directly compatible with the "hint" String parameter:
 - You have to put the "hint" somewhere in the Context to use it as
   you currently do;

You can do just the same with a single Object parameter. I am going
to repeat myself yet again:

 - Just a role:
    lookup("myRole");    // Role with single implementation

 - the hinted flavor:
    lookup(new RoleAndHintKey("myRole", "myHint"));    

 - compatible with the new Context flavor:
    lookup(new RoleAndCtxKey("myRole", myContext));   

  
> > Please try to read what I wrote with a bit more attention, 
> > otherwise repeating things again and again will not result in any
> > gain.
> 
> I'm trying, trust me. You can help me though - I put one question into
> my previous email: "However, if you want the ECM (the implementation) to 
> manage things other than components, while still letting it implement a 
> CM interface, then I'm with you."
> 
> So, do you?
> 
> What if we had the ServiceManager interface replace the current 
> ComponentManager
> interface which was mentioned in this thread previously, and then:
> 
> interface ServiceManager {
>   Object lookup (String role);
>   Object lookup (String role, Context ctx);
> }
> 
> interface ComponentManager {
>   Object lookup (Object key);
> }

PERFECT.
=:o)

We agree, we agree, we agree!!!!!!!!!


I had already proposed EXACTLY that (maybe you lost a bit of this thread).

I am going to quote an answer I gave earlier today to Peter:

> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 11, 2002 2:54 PM
> ...


First Peter wrote:

>> It may be clearer to use the term ServiceManager rather than 
>> ComponentManager 
>> because that has a easier to grok description of what a CM is 
>> meant to do. 
>> 
>> ...

Then I wrote:

> ...this makes it much less confusing. =:o)
>
> Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 to have a 
> brand new ComponentManager which could provide the core functionality for
> the ServiceManager (now called ComponentManager).
> 
> So, Avalon would get BOTH a Service Manager and a Component Manager. This
> would make the framework quite a bit more generic and I think it would be
> of better use for projects like Ant-Myrmidon and Cocoon.

> I mean, my "Sitemap" does a lot of the same that Cocoon's Sitemap does and
> I just use my standard ComponentManager and Configurator functionality for
> that. They have to do a lot more manually I think.

We agree, we agree, we agree!!!!!!!!!


> class ExcaliburComponentManager implements ServiceManager, 
> ComponentManager { ... };
> 
> interface Composable {
>   void compose (ServiceManager sm);
> }
> 
> interface Componentized {
>   void componentize (ComponentManager cm);
> }
> 
> Would this suit your needs? Since you do not intend to use the CM 
> to lookup
> what Avalon calls components, having a new interface would solve your
> problems, right?
> 
> /LS

Yes, but in terms of _implementation_ a ServiceManager could
reuse almost all the code from a ComponentManager.

I am going to present a small change to your structure just for
the sake of exchanging ideas. I am aware that such naming might
not be possible since there is the big problem of breaking with 
the past names and conventions. IMO the _ideal_ naming and 
structure, would be something like:

interface ServiceManager {
  Object lookup (String role);
  Object lookup (String role, Context ctx);
}

interface ComponentManager {
  Object lookup (Object key);
}


interface Serviceable {
  void serve(ServiceManager sm);
}

interface Composable {
  void compose(ComponentManager cm);
}

class ExcaliburComponentManager 
  implements ComponentManager
{
... 
};

class ExcaliburServiceManager 
  implements ServiceManager
  extends    ExcaliburComponentManager 
         // or wraps or reuses in some other way
{
...
}


Well, compatible at last! I never lost the hope!
=;o)

I like very much this structure.

Great!
=:oD


Have fun,
Paulo Gaspar



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

Reply via email to