Alan, Anthony and all,

> > - A mixin may contain a meta-mixin which defines class side behavior.
>
> I was leaning towards getting rid of metaclasses.

When I started my mixin implementation, I used the concept of meta-mixins
(methods defined there go into the class side) in order to be compatible
with the current Squeak implementation and have a first prototype I can use
for experiments as soon as possible.

However, reading the posts you sent this weekend gives me more and more the
impression that you guys are effectively willing to do serious changes on
the Squeak kernel, and I *really* hope I am right!!
Of course, this gives the whole issue a new dimension because it allows us
to do the thing the way they should be and not only in a slightly better way
that still has to be compatible to the original ST-80 concepts.

As far as metaclasses go, I completely agree with Alan. The benefits of the
ST-80 metaclasses are not really worth the pain and the complexity they add
to the system. And I also agree that something between a class-based and a
prototype-based approach might be the way to go.
Nevertheless, I think that a nice meta-architecture (a MOP (meta object
protocol) in case of traditional object-oriented languages) adds a lot of
value to the system because it allows reflection and adapting/experimenting
with a system in a very clean way (changing the message passing semantics,
changing the class structure (e.g. slot management), etc.). However, a good
meta-architecture should be designed in a way that allows a "normal"
programmer to deal with the system in the exact same way as if it wouldn't
be there. This means that a "normal" programmer should not at all have to
interact with the meta-level in order to do ordinary programming work. At
the same time, a good meta-architecture should allow a meta-programmer to
adapt the behavior of limited parts of the system in a flexible and clean
way without affecting the semantics of the other parts. (In traditional OO
languages, a good MOP easily allows to change the behavior of a single class
by exchanging its metaclass. This does not affect the other parts of the
system nor does it require changes in the VM).

Unfortunately, the ST-80 meta-architecture does not fulfill these
requirements. It mixes up meta-aspects with ordinary programming by urging
the programmer to define class-related aspects in the meta-class. As an
example, a programmer needs to define a constant that applies to all the
instances of a class (ordinary programming) at the same level as the
method-dictionary of the class is managed (meta-programming).
Besides the fact that this mixin of normal programming issues with
meta-programming aspects makes the language more complicated for the normal
programmer, they also have negative impacts on the language itself. As an
example, this issue would make it unnecessarily hard to add good security
mechanisms to Squeak because such security mechanisms would require to
forbid (most) operations on the meta-level.
At the same time, the ST-80 meta-architecture is not designed to allow a
meta-programmer to adapt the behavior of certain classes without affecting
other parts of the system.

So, I'm curious to hear and discuss more about your ideas of a new Squeak
kernel. It's a very exciting perspective and I think that it is a great
chance. So, let's not miss it and do it right!

Cheers,
Nathanael

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Anthony
> Hannan
> Sent: Sonntag, 24. Februar 2002 18:43
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Getting rid of metaclasses (Was: Behaviors vs Modules)
>
>
> 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.
>
>