One part of this that I've been thinking about is messaging to  
collections vs. messaging their contents.  For the sake of argument,  
I took the term "messaging" very seriously and thought that  
essentially, we're talking about an object with multiple message  
"ports".  One port is for talking to the collection, the other is for  
talking to the objects contained in the collection.

So each object can have multiple ports, with all ports being  
accessible, maybe by a prefix message or some other mechanism.  One  
port is made the default port, usually this is the port talking to  
the object itself.  For proxies, the default port would be the port  
that talks to the "remote" object, with the local port being  
accessible indirectly.

How does this relate to roles?  I am not 100% sure, but the  
literature on software architecture that I am so fond of also uses  
the terms port + role, in complementary fashion.  If you recall,  
software architecture divides the world into components and  
connectors.  Components are points of computation, possibly state,  
while connectors, well, connect components together.  The way  
connectors connect components is that they have roles, which can be  
filled by ports of components.

Taking this cue literally (which I am not at all sure is correct),  
it would mean that objects don't have roles, they *fill* roles of  
connectors by attaching one of their ports (which can be outgoing as  
well as incoming) to that role of the connector.

Applying this at a low level, "Message" is a connector with roles  
for receiver, sender and arguments.  At a higher level, a morph could  
have different ports in order to fill different roles.  How it  
acquires those ports, wether by implementing them itself, inheriting  
or delegating, is of no concern.  Roles and ports could use type  
information (but of what kind?) to do checking and also to assist in  
auto-connection.

Other connection mechanisms such as Fabrik's dataflow connections or  
ThingLab's constraints seem to all fit very well into this same  
scheme.  This could just mean that it's essentially vacuous, but  
there does seem to be something there that looks useful.

Hmm...

Marcel

> From: Alan Kay <Alan.Kay at disney.com>
>
> I think your POV on this (below) is a very good idea (and it has  
surfaced a
> number of times over the last 25 years or so without quite getting  
enough
> energy for a useful implementation). I believe that this approach  
really
> would amount to something, and concur with your speculations that  
replacing
> hierarchical inheritance with sideways "roles" (in the old days called 
> "aspects" or "perspectives") would make things both simpler and more 
> powerful. I was quite taken with the Goldstein and Bobrow approach  
in their
> PIE system built at PARC using Smalltalk-76.
>      A good place to start might be to reformulate the Morphic and  
end-user
> subsystems in Squeak into a rolebased model. For example, over the  
years,
> I've toyed with end-user objects that have the following roles:
> * a visible/graphic role
> * a collection/carrier role
> * a "participant in a simulation/app" role
> * a basic object role
>
> As you note, it makes much more sense to have these be "sideways"  
than be
> hierarchical.