At 10:26 AM 1/28/2002, you wrote:
>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.

Andreas,

I had to go for another couple of laps around the track before I really saw 
what you meant.  I could have my MixinMetaclass, which has an instance 
variable holding my contextClass.  I could have the various '#compile...' 
methods be overridden in Class to do a 'self class thisClassCompile:...' 
(what is the opposite of meta?  ;)  and implement the appropriate 
activities there that I could control with different metaclass classes.  :)

Is this a reasonable change to the system?

Cheers,
Robert


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