Les --

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.

Cheers,

Alan

---------

At 6:28 PM -0800 2/11/00, Les Tyrrell wrote:
>Leandro Caniglia wrote:
>>
>> Les.--
>>     I like your thoughts about using category
>>     theory in Smalltalk!
>>
>> What do you mean with 'category theory'? Are you thinking
>> about mathematical categories (objects, arrows, functors,
>> etc)?
>>
>> /Leandro
>
>See Alek's message about that. Like I say in my own message,
>I'm not that familiar with it, although Alek's comments
>reminded me of something that I once had in mind.
>
>If you are wondering what I meant by my own comments, that
>could be very different from category theory for all that I
>know.  What I had in mind was making Roles into a part of
>the normal Smalltalk model, alongside such things as Classes
>and methods, and considering a different approach to building
>classes that did not involve the classes having the inheritance
>relationships, but rather having the Roles carry those.  Whether
>that would ever actually amount to anything I have no idea.
>
>I think that this is possible in Squeak or VisualWorks because
>about the only vm requirement for method lookup is that the method
>dictionary be found in a particular slot of an object's "class".
>Beyond that, there is almost no requirement that the "class" be
>a, uh, "Class".  So, it could be a Role instead.
>
>I'm sure that there would be other problems with this- but then,
>the notion is that as far as I the programmer know, I am composing
>the class out of Roles.  The underlying mechanisms supporting
>such a virtuality can be very different from what the programmer
>percieves.
>
>-les