avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: ServiceManager/Serviceable -> Director/Actor?
Date Mon, 18 Feb 2002 13:46:13 GMT
Antti Koivunen wrote:
> Hi there,
> 
> When I first stumbled into Cocoon 1 a few years back, I remember really 
> liking the intuitive names of the core interfaces, Director and Actor. 
> Given the confusion surrounding Component/ServiceManager, and the 
> somewhat valid argument that Object != Component != Service, I think 
> this might be something to consider.

This was Avalon version 1.  It was never a released project, just used
as the basis of some other projects--and avalon continued to evolve.



> The main purpose of Component/ServiceManager is to look up an object 
> that matches the specified role (behavioral interface), so the idea 
> would go well together with the Director-Actor naming scheme. Having 
> intuitive and 'fun' names for the core interfaces could also make the 
> framework more approachable (Composable???). Programming is serious 
> enough as it is :)

It has the same problem... Director returns something that implements
Actor.  We do need something that returns an Object.



> Personally I don't have any problems with the name ServiceManager. 
> "Providing the service specified by the role" makes perfect sense to me, 
> and I also like the term Serviceable. But as these are the names we'll 
> be looking at for a long time, I thought everybody might want to have a 
> say.

I have one issue--A service is more narrow than a Component, and the
return type is more broad.  Therefore, ServiceManager is not a good
name.  Resolver is a good name because it can "resolve" objects of
any type.

The psuedo-protocol approach allows the simplification and narrowing
of what you expect.  I.e.: when you look up a Component you want a
component.  When you look up a file, you want a file.  The Resolver
would be able to communicate with the Container and have that resolve
all the references.  It works well.

You can even have the psuedo-protocol be the ROLE of the object you
want. I.e. when you want a Transformer, you would do this:

resolver.resolve( Transformer.ROLE ); // gets the default transformer.
resolver.resolve( Transformer.ROLE + ":foo" ) // gets the "foo" transformer.

And yes, Cocoon's sitemap uses the concept of default components!

> 
> The new classnames could be:
> 
>   org.apache.avalon.framework.role.Director
>   org.apache.avalon.framework.role.DefaultDirector
>   org.apache.avalon.framework.role.Actor
>   org.apache.avalon.framework.role.ActorException
> 
> These remind me of the practical names I've used in AOP (e.g. Group, 
> Member), but some people might prefer technical terms. The idea could be 
> extended with terms like agent, audition and studio (though not sure for 
> what purpose).
> 
> So, is this way too silly or actually something to consider?

I think it is a step backwards.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
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