Hi Alan,

I'm pleased that you favor bringing up the subject of roles /
aggregation / composition again.

On Sun, 24 Feb 2002, Alan Kay wrote:

> Yes, they 
(metaclasses) 
> were done after I left and, as I have written before, 
> IMNHEO do not pay for their added complexity.
> 
> However, I have been in favor of the late 70s PARC "multiple 
> perspective" way to make objects that was pioneered by Ira Goldstein 
> and Danny Bobrow in their PIE system (the most interesting extension 
> of Smalltalk that I've seen).

Thank you for this evaluation!

>       The thrust of this model is that objects have multiple 
> roles/views/perspectives -- for example, from the outside, many 
> objects in Squeak could be dealt with as playing a graphics role, a 
> collection/valueholding role, an object role, and various roles with 
> the objects it relates to (e.g. it could play any or all of: a parent 
> role, an offspring role, a teacher role, a student role, a manager 
> role, and employee role. etc.). These roles are all additive 
> "sideways" relationships.

>       Goldstein and Bobrow eventually found a very interesting way to 
> implement these enriched objects: they used Smalltalk instances for 
> each role/perspective. So a PIE object could be made from many 
> Smalltalk objects.

>       This allowed each role to have its own name space of instance 
> variables. They decided that it was better to make dynamic relations 
> to unify variables that were logically the same across perspectives 
> (as opposed to mapping all the variables of all the perspectives into 
> a single Smalltalk instance and dealing with the possible clashes).
> 
> Note that this interesting organization is rather independant of the 
> particular abstractions chosen for making types of instances. That 
> is, it can be used with a class-based system, or a prototype-based 
> system, or something in between (which is what I think we should 
> invent).
> 
> Cheers,
> 
> Alan

I would like to see Squeak beeing developed into this direction. Actually
this point reminds me of a slightly polemic discussion initiated 
by Stephane Ducasse last June about the class Morph having about 1000 methods.
(The
thread: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/squeak/573455)

In particular I had asked Ned Konz in that thread about the problems 
of understanding how the class Morph works and the conclusion was IMO 
that the problem arises from the fact that the class Morph is an
aggreation/composition of many roles which are not easily seen.



Some of a Morphs many roles are summarized in 

(Ned Konz)
http://aspn.activestate.com/ASPN/Mail/Message/squeak/619572

> It all depends on what a Morph is supposed to be able to do. Note that
one of  
> the reasons that Morph got bigger was that specific functionality got
moved  
> into it: 
>  
> * any morph can be a button (not just *Button*Morph classes) 
> * any morph now knows how to do fancy layout (not just AlignmentMorph) 
> * any morph can be dropped into a piano roll 
> * morphs know how to print themselves 
> * morphs have an extendable set of halos 
>  
> etc. There's a lot of functionality that *any* morph possesses that
would be  
> hard or inefficient to reorganize. Some of this has already been done
(like  
> with layout policy objects). 


I think Ned stated the problem in a good way in the last message of that
thread

http://aspn.activestate.com/ASPN/Mail/Message/squeak/619684


I remember that Scott Wallace likes having base objects which can do a lot
because they are easier to extend. 
And I think you have written that you like massively polymorphic objects
as well.  In the meantime I began to appreciate this idea which I was
opposed to from a more classical software engineering point of view.
(Actually there it is an indication of bad design.)

For the user (includes "application" programmer as user) it is
conceptually nice  to have objects which can do many things. 
>From the student, fix, enhancement, research programmer point of
view one would like that the system is easier to understand.
In Java for example people think this is resolved in adding more 
and more classes but I think it is difficult there as well to see the
big picture. A lot of effort goes into using graphical methods (UML)
to see what is happening. That's helps but does not resolve
the problem I think. (It's astonishing that this is not the case
in the Smalltalk culture).

One of the major problems seems to be that just one of the 'big'
relations - implementation inheritance - can easily be used.
 
Inheritance has support by the tools in the system
while aggregation/composition needs a lot of manual rewriring and 
cannot been seen easily detected afterwards.
(Of course there are Inspectors and Explorers that help)

It would be nice to automatically support the concept of
aggretation/composition:
- an object has different roles.
- there are browsers that show the aggreation / composition better.
  (within a compound object)


Taking the Morph class example:

A Morph may have a MorphExtension. 
(http://minnow.cc.gatech.edu/squeak/1935)


A MorphExtension may have otherProperties (an IdentityDictionary)
(http://minnow.cc.gatech.edu/squeak/1935)

Many methods of Morph just rewire manually to MorphExtension and to the
otherProperties dictionary.

If one could communicate this aggregation more clearly and support it with
some kind of tools that would help considerably understanding the system.

I think most people on this list have problems understanding the Morphic
framework although it is probably simple and elegant given the right
design clues. But that does not show through. 


To sum up: taking Squeak still as a research vehicle I would welcome
Squeak developing in this direction. It is platform independent and works
astonishingly smooth compared to the big problems other people are
struggeling with. I agree with you in the sense of your 'the computer
revolution hasn't happend yet'. 
I consider this step to be a stelp in the right direction.

Cheers

Hannes Hirzel


ALI Akan / ALI Swahili
ICT department
University of Zurich
http://www.spw.unizh.ch