avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [proposal] say no to ROLE
Date Sat, 17 Jan 2004 23:53:25 GMT
On Saturday 17 January 2004 15:21, Leo Simons wrote:
> I Am Pro-ROLE
> -------------
> I have used and written dozens of components that define ROLE, and it
> has always worked perfectly for me.

> The main useful thing about ROLE for me is that you define it in the
> work interface, and even in deep inheritance it is always clear (because
> its 'lightweight forced') what exactly constitutes the work interface.

Could you elaborate on this a bit?? I have probably asked this before, and I 
have yet to see the light.

Concretely; The analogy often brought up is the cast at a theatrical play. The 
play consists of Roles. There are any number of Actors. Each actor plays one 
or more roles. This setup is clear, now...
In Avalon, the Role is the ROLE, and the Actor is the component.

Does anybody find the fault in the logic/analogy above?

The ROLE is part of the PLAY. The Actor performs the Role. The Same Actor 
(read component) can perform (in a theatrical play) Any Role of the Play. The 
Actor's interface (in a theatrical play) is his/her 
experience/training/understanding of Acting, so that the director can issue 
directives like "be more subtle in the expression of grief" (which I, 
non-Actor, wouldn't have a clue what that would mean).

I can't see how this is the case with Avalon Roles. 
Is the PLAY restricted to a single interface and a single Role? Probably not. 
Then if a bunch of interfaces makes the Play, then I can't swap the actors to 
play the different roles. In fact, it is like saying one particular actor can 
only play one type of Roles.
But then, someone will say, a component can implement many different 
interfaces and by that play many roles - I say SoC !

I am more against the terminology (ROLE) than I am against the use of String 
as lookup, and Leo's version of encoding lookup information into that String.
I also know that the terminology has been around quite a while, but that 
doesn't mean it is good (compare War).


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

View raw message