> 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

I've tried both approaches to some extent (the same object and several
objects). Several objects is much easier to implement and you can get some
mileage from it, but I don't think it would hold up as a general language
construct. If you really apply the perspectives idea consistently, every
object in the system would have many perspectives, for example the whole
meta-system would be replaced by several perspectives.

When I did this I hadn't realized that you can use a kind of selector
namespaces to do a simple version of multiple perspectives for the same
object. Perhaps I had gotten longer along the way then.

> 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).

My tuppence would be that perspectives fruitfully may supersede both of
these. I recently wrote a reflective algorithm that examines the structures
of objects to find possible combinations, and realized that since this was
perspectives-based, the reflective code wasn't "meta-level" programming as
it would be with classes, but instead it was just the plain ol' object
looking at a structural description itself, i.e. from a "structural" or
"descriptive" perspective.

In a more general example, to find out the names of all of an object's
instvars you wouldn't go to its class, i.e. the meta-level, but ask the
descriptive perspective of the object, which knows its structure.

Another perspective would be the "prototype perspective", where you could
e.g. ask for the "prototypical value" of some instvar, as in a default
value, (which is what a prototype provides).

I also began sketching what the Smalltalk meta-object implementation
(Behavior, Class, Metaclass et al.) would look like if done in this way, and
although I didn't complete it, it seemed to become _much_ more
understandable. Everything that the headspinning metasystem does now would
be done by the object itself, from a few different perspectives. No more of
those "what's the class of the Object class' superclass class" riddles.

> Just one aspect of Self.  We would still have class objects that hold
> methods and instance variables names and a single superclass.  They
> just wouldn't be directly reachable from globals.  And we wouldn't
> have multiple inheritance via delegated parents.

It seemed to me that perspectives provided a good way of getting away from
the problems of multiple inheritance. There is an Oopsla paper that makes a
similar argument. ("The Point of View notion for Multiple Inheritance",
1990) 

By the way, there has been a fair bit of work done on perspectives after
PIE. The work on "roles" is also related, and of course, all that on
subjects and aspects, too, sometimes it is more relevant, sometimes less.

Henrik