Sorry, but I couldn't just lurk on this one,

I think that there is a place for both the current hierarchical inheritance
(based on accretion of structure, function, identity, and participation in
relationships) and the roles that objects can play (based on the properties
that objects can exhibit.)

But this would require a drastically different presentation/selection
mechanism. I would start with a VRML browser capable of presenting objects and
their relationship in 3D. (I've laid out complex databases as points and lines
on a sphere nested according to the dependent relationships. It works. VRML
gives you much more "space" to lay things out and putting then in what looks
like nested spheres reveals "depth" of relationship at a glance.)

Even then, the potential relationships wouldn't be clean like the current
hierarchical simplification. The relationships rapidly would become a tangle
unless you had some excellent software to lay out the possible routes. (The
entire thing could be laid out using only four colors though :-)

I mean, think of it, you're basically asking the computer to present you with
the equivalent of the subjective mental states of people visiting someone in a
hospital room and responding to a request to sit down.

Will they sit on the bed, on a chain, on the floor or perch their butts on the
radiator next to the window? All of these objects can play that role by virtue
of being an approximately perpendicular surface of approximately the right
height and the selection depends on situation external to the the nature of
the objects themselves but internal to the participant or participants.

This would require a multitude of views, as Mr Kay has explored, since objects
can play roles based on their properties that they were never designed to
play. OR it would require a browser capable of making inferences based on the
nature of the objects in described in the current hierarchy in order to select
and rank them according to suitability.

However that would require information that simply isn't there currently since
there is no equivalent to the physical reality of flat surfaces around a
hospital room. This is a _hard_ problem in visualization.

-Charles-A.


Alan Kay wrote:

> 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