Alan,

The ideas of having multiple roles/views/perspectives associated to an
object sounds very interesting and promising. I'd really like to know more
about these PIE system and its implementation. If you have any pointers to
some information, please let me know.

Thanks,
Nathanael


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Alan
> Kay
> Sent: Sonntag, 24. Februar 2002 20:18
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Getting rid of metaclasses (Was: Behaviors vs Modules)
>
>
> Yes, they 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).
>       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
>
> --------
>
> At 12:42 PM -0500 2/24/02, Anthony Hannan wrote:
> >Nathanael <n.schaerli at gmx.net> wrote:
> >>  - A mixin may contain a meta-mixin which defines class side behavior.
> >
> >I was leaning towards getting rid of metaclasses.  A class reference
> >like "String" would instead reference the String prototype, and class
> >methods would be moved to instance methods under an appropriate category
> >like "instance creation".  Class variables can be replaced by instance
> >methods that store arbitrary constants, instead of just literals.  This
> >allows overriding without the need to use class instance variables.  And
> >the prototype can serve as an example (enhancing documentation) or as a
> >real prototype to copy.  The prototype (or any instance) would respond
> >to #new the same as today by creating a brand new instance.  It would
> >respond to #copy by copying itself.  So the user has a choice.
>
>
> --
>
>