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.


--