Couple more thoughts on this:

In thinking about how I would accomplish this, two approaches come to
mind:

1) Make Squeak better handle anonymous classes...this way you can create
anonymous subclasses to handle "instance specific" behavior and state.
This is not so much an implementation approach, but rather a way of
thinking about the problem.

2) Forget messing with Metaclass and create a new subclass of Behavior.
Call it "UniBehavior" for the lack of a better word (and that's a bit of
a misnomer).  Your objects that have instance specific behavior and
state would be instances of an instance of UniBehavior**.  Let's call
the instance of UniBehavior a UniBehaviorInst.  A UniBehaviorInst's
superclass will point to the Class (or Metaclass) that you are trying to
instantiate with instance specific behavior and/or state.  The
UniBehaviorInst's methodDict will contain the instance specific methods.
The UniBehaviorInst instance will be your object with instance specific
behavior and state.  You will instantiate a UniBehavior instance in such
a way that it has enough slots to hold all of the UniBehaviorInst's
superclass' variables, plus any of its (the UniBehaviorInst) own.  The
compiler will need to be able to deal with compiling accesses to inst
vars that are specific to a given UniBehaviorInst; you'll need to handle
shape changes (when inherited classes change); you'll need to figure out
what to do with method source code on these guys; etc.

Number 2 might be a way of implementing number 1.  In any case, it is
worth looking at the ProtoBehavior and Mirror classes in:
http://spair.swiki.net/21 (there are some really clever/hacky tricks
done to track which slots are parent slots, which methods are slot
accessors, etc).

** For all of your objects that have instance specific behavior and/or
state, the following will be true:

	anObject class class == UniBehavior

For the longer term, I think you have to start considering a move to an
optimized object memory layout similar to Self with the corresponding
interpreter changes.  Given your time frame, this may or may not be an
option.  But, I would certainly love to see progress in that direction.

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Andreas Raab
> Sent: Thursday, December 05, 2002 4:17 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Metaclassing
> 
> 
> Hi Guys,
> 
> Has anyone ever tried to provide "Metaclass behavior" by some 
> other class than Metaclass itself?! I have the need for 
> something that is "similar to but not quite the same" as 
> Metaclass' behavior (what I am effectively trying to do is to 
> build a clean representation of Uniclass behavior as in eToys 
> which may require instance ... err ... class ... err ... meta 
> ... oh what the heck, STATE).
> 
> What I am looking for is some primer on how to 
> replace/subclass Metaclass (it drives me nuts just thinking 
> about the fact that a subclass of Metaclass would also be an 
> instance of Metaclass....) and/or any experiences in doing 
> this. In particular little bits like "don't forget to XYZ or 
> else the system will break" would be helpful ;-)
> 
> Cheers,
>   - Andreas
> 
> 
> 
>