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
>