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