Rob,

What an interesting problem! As Nathanael has already shown there are
various implications when you start breaking the parallel hierarchy. I
think that (probably) the best you could do for a practical solution
would be to factor out the recompilation behavior. E.g., one possible
solution would be that MetaClass itself knows what kind of compiler to
use and you can therefore redirect queries to the "meta meta class" (now
it's getting funky ;-)

Incidentally, once you're at this level you can do whatever you want.
There is no reason for Mumble class to be an instance of MetaClass - the
hierarchy restrictions doesn't go that far.

Cheers,
  - Andreas

> -----Ursprüngliche Nachricht-----
> Von: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] Im 
> Auftrag von Rob Withers
> Gesendet: Montag, 28. Januar 2002 00:32
> An: squeak-dev at lists.squeakfoundation.org
> Betreff: [Q] mixin pattern - how to use an alternate Behavior 
> for Class
> 
> 
> I am trying to create a mixin class which compiles it's 
> methods 'in' the 
> scope of a different class.  One way to go would be to have 
> class side 
> #compile methods which switches the class used to compile the 
> method in.  I 
> would need a classVariable to hold this contextClass and off we go.
> 
> An alternative mechanism that I am exploring, is to have a different 
> subclass of ClassDescription (or Class), which has an instance method 
> contextClass, and the compile methods are overridden on the 
> instance side 
> of this MixinClass.
> 
> So I have a MixinClass, which has roughly identical protocol 
> to Class and I 
> am now adding a set of methods to ClassBuilder to create this class 
> (instance of MixinClass).  The problem is that I am not sure 
> what to set 
> the superclass of the Metaclass instance too.  (1b) If I 
> leave it alone, my 
> class is an instance of Class.  (1a) If I force it to 
> MixinClass, then my 
> class is an instance of MixinClass and my instance methods 
> are ok, but the 
> class-side confuses me a little - I have broken the metaclass 
> superclass 
> inheritence.  Do I really need to have a MixinProtoObject to root 
> everything with MixinClass class as the first metaclass 
> superclass, or can 
> I stitch myself into a different point in the hierarchy and 
> still have my 
> class be an instance of MixinClass, rather than Class, but 
> maintain the 
> correct metaclass inheritence?  I believe it all relies on the 
> implementation of 'meta new', especially with 
> Interpreter>>formatOfClass: 
> aClass, where aClass is a metaclass instance.
> 
> Cheers,
> Rob
> 
> 
> 
> 1a)	meta _ Metaclass new.
> 	meta
> 		superclass: MixinClass
> 		methodDictionary: MethodDictionary new
> 		format: MixinClass format.
> 	newClass _ meta new.
> 
> 
> 1b)	meta _ Metaclass new.
> 	meta
> 		superclass: newSuper class
> 		methodDictionary: MethodDictionary new
> 		format: MixinClass format.
> 	newClass _ meta new.
> 
> 
> 
> 2)	newClass
> 		superclass: newSuper
> 		methodDictionary: MethodDictionary new
> 		format: newFormat;
> 		contextClass: aContextClass;
> 		setInstVarNames: instVars;
> 		organization: nil.
> 	^newClass
> 
>