Henrik --

It would be great if you could make some of the postPIE work 
available (like the paper you mention below).

P.S. Actually there is a way to make this work for every object ...

Cheers,

Alan

------

At 4:32 PM +0000 2/25/02, Henrik Gedenryd wrote:
>  > 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


--