Hello everybody,
I'd like just to mention that while looking closely at this topic a year ago I came out with the conclusion that, in some situations, we could "get ride of" both metaclasses and objects. I implemented a metaclass whose instances had two special functionality: 1) when they receive the message #new, instead of creating a terminal instance, they create an empty subclass of themselves. 2) they manage values for their instance variables.
That is, each instance of such metaclass (called it an "autonomous class"):
1) is a metaclass in that it responds to the new message by creating a new "class"; 2) is a class in that it keeps structure and behaviour definition for its "instances"; 3) is a terminal instance in that it keeps value for its instance variables.
But being a sort of all these things, it is basically non of them. However, they seems to me much closer to classes than instances and metaclasses, while providing a functionality comparable to that of prototypes. Each new "instance" can specialize structure, behaviour and values of its "class".
I used these "creatures" as a means to ensure the "continuity" in the modelling activity realized by non programmer domain experts, by avoiding terminal instances whose structure and behaviour, by default, can not be further specialized. It seems to me that autonomous classes can be useful for implementing Players in Squeak. Unfortunately, I've not yet had time to test this idea.
Cheers, /reza razavi
A 15:10 24/02/02 -0800, Dan Ingalls a écrit :
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.
I think this is one of the "sweet spots" to aim for in a variant of
Smalltalk. For at least a year in the early history of Squeak, John Maloney and I were "just about" to do exactly what you propose, namely get rid of metaclasses and instantiate from prototypes. It simplifies the model, keeps the benefits of class organization, and makes things "feel" more object-oriented.
The one other thing we were going to include is the ability to refine
behavior starting with the object rather than its class, as in
make me respond to <method description> or make a copy that responds to <method description>
This just takes a couple of methods and completes the model for working
with objects, without departing from Smalltalk's semantics and organization by classes.
Yeah. Do it.
- Dan