Andreas and Stewart,  comments interspersed....

> -----Original Message-----
> From: Andreas Raab [mailto:Andreas.Raab at gmx.de]
> 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 ;-)

Right, but I also needed to model that a Class' methods are is targetted to
a different context.   My MixinClass holds the context.

> 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.

Wait a minute, you have a point here.  If I use an instance of
MixinMetaclass for the metaclass, then could my 'new' instatiate the right
kind of Class for my class?  It all depends on 'formatOfClass:' in the
interpreter I believe.  This is where I loose the thread of causality.


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

Yes, I have done this and it mostly works.  My goal here is to have a
mechanism to research lookup algorithms and metaclass structures _in the
image_.  As far as maintaining identity under delegative self-sends, we
really want Self style delegation, of which Stephen Pair has a running
implementation.

> 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.

But still reliant on the methods that the Wrapper has to implement.  My
redirector redirects *all* message sends to it.  It is really a first class
Reference object.

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

yep.

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

yes and no.  There are shortcomings with this solution which does not solve
my problem.  This *is* much more fun!

cheers,
Rob



> 
> > -----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
> > 
> > 
> 
> 
>