Hi Rob,

You might consider achieving a mixin effect by doing it at an instance level using delegation.

I've done this by having a wrapper object of class Entity within which I override doesNotUnderstand: to delgate to a wrapped subclass of Role object. Roles are "mixed in" at the time of creation of the Entity. As an optimisation, at the first delegation after the role classes are searched to find the one that does actually understand the incoming method, a direct invocation method is compiled on the fly.

This mechanism relies on method names being unique within each role class.

It's a lot simpler than messing with the meta, but not nearly as much fun!

Cheers,

Stewart

----------
From:  Rob Withers
Sent:  28 January 2002 11:32
To:  squeak-dev at lists.squeakfoundation.org
Subject:  [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