Getting rid of metaclasses (Was: Behaviors vs Modules)
Alan Kay
Alan.Kay at squeakland.org
Sun Feb 24 19:18:11 UTC 2002
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.
--
More information about the Squeak-dev
mailing list
|