Hi Rob,

Your problem with positioning MixinClass in the ST (meta-) class hierarchy
is pretty interesting 
and in fact, I also run into similar problems when I played around with new
meta-metaclasses 
(subclasses of Metaclass) which allow certain classes and objects to have a
different 
semantics...

As you surely know, the ST-80 (meta-) class hierarchy uses parallel
inheritance between classes 
and meta-classes. If the class 'Model' inherits from Object, than the
implicit metaclass 'Model 
class' inherits from 'Object class'. On one hand, this seriously restricts
the freedom of the 
programmer, but on the other hand it guarantees compatibility between the
class and the 
metaclass level. If we don't have parallel inheritance, the following may
happen:

Assume that in 'Object' defines a method 'foo' which calls a method 'boo'
that is defined in 
'Object class':

Object>>foo
   self class boo

Object class>>boo
   "Anything"

Now, assume that the 'Model' inherits from 'Object' and 'Model class' does
not inherit from 
'Object class'. This means that sending the message 'foo' to an instance of
'Model' would result 
in an error because the method 'boo' is not defined on the class side!

In case (1a) you break this parallel inheritance hierarchy because
'MixinClass' is a subclass of 
'ClassDescription' but 'MixinClass class' is no subclass of
'ClassDescription class' (in fact, 
'MixinClass class' == 'MixinClass'). In your concerte example, this means
that 'MixinClass' inherits 
from:

ClassDescription
Behavior
Object
ProtoObject

but 'MixinClass class' (== 'MixinClass') does not inherit from
'ClassDescription class', 'Behavior 
class', etc.

In particular, this means that all the method defined on the class side of
'Object' are not 
available on the class side of 'MixinClass'. Since this includes relatively
important methods (such 
as managment of dependencies), this might lead to a problem. However, if you
only use 
'MixinClass' in a restricted manner, it can work.

BTW: I am thinking about a more powerful and cleaner MOP for Squeak that
would ensure the 
inter-level compaitibility, but would still allow more flexibility. I hope
I'll have the time to work on 
it more, soon. It would be so cool if Squeak would allow classes with
different metaclasses. 
Then, it would be very easy and safe to change the slot access or the method
dispatch for 
certain classes without having to recompile them.


Now, to my work on mixins. Whenever I was designing and implementing an
application in 
Squeak (or Smalltalks), I have felt very limited by the fact that there is
only single inheritance. As 
soon as there are classes with responsibilities that fulfill more than just
one single aspect, this 
urges the programmer to duplicate code. On the other hand, I have never been
happy with the 
rather complex multiple inheritance algorithms where the programmer easily
looses track of 
what actually happens and which method is finally invoked (such as in C++).
Java's interfaces 
are actually very nice (simple), but they also don't solve to code
duplication problem. So, why not 
using a simple concept that is similar to interfaces, but actually allows
implementations (but no 
state)?

--> Idea of stateless mixins with the features such as:

- Mixins are first class entities (obvious in Squeak)
- Mixins have reflective aspects such as 'provided' and 'required' methods.
- The required methods are basically the glue that is necessary to use a
mixin in another class or 
another mixin.
- If a class implements several mixins, they are not ordered. This means
that the programmer 
has to resolve all the conflicts manually.
- An extension of the browser allows to see which mixins are implemented by
a class, how the 
glue methods are defined and how the conflicting methods are defined.
- Mixins can be automatically derived from existing classes. Thereby, access
to instance variable 
and the class is automatically replaced by methods that have to be defined
when the mixin is 
used (required methods). A class and the derived mixin are (per default)
related. This means 
that when a method of a class gets changed, the corresponding mixin gets
also adjusted.

I am just about to implement a first version of these "Stateless Mixins" 
with features as 
mentioned above (and some more). The main goal is to be able to group a
"(partially) 
independent set of related methods" as a first class entity and to reause
them in a very simple 
way (therefore no state). I think that one of the keys for that is a good UI
that allows the 
programmer to see what is actually going on.

Cheers,
Nathanael

> Hi Stef,
> 
> Actually, mine is much more special case than MixinClass.  It is called 
> RedirectorMixin.  I intercept method lookup, in the vm, and redirect into 
> the image so I can manipulate this lookup.  I am writing the Mixin in
> order 
> to have class-based methods to dispatch through.  The reason for creating
> a 
> special class was to allow this class to be manipulated in the browsing
> tools.
> 
> I'm quite sure there are other aspects of mixin that I am not addressing
> in 
> my special case.  ;)    I look forward to hearing about them and from 
> Nathanael.
> 
> Cheers,
> Rob
> 
> At 02:06 AM 1/28/2002, you wrote:
> >Hi Rob
> >
> >we are working on mixin (not like yours in fact) mixin are not only about
> >compiling in a different scope ;)
> >
> >I think that we have kind of similar questions ;)
> >Nathanael will certainly get ion contact with you.
> >
> >Stef
> >
> > > 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
> > >
> > >
> 
> 

-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
  Nathanael Schärli
  Rüttenenstrasse 41
  CH-4515 Oberdorf, Switzerland
    Phone: +41 32 622 89 03
    Fax:   +41 32 621 78 50
    Email: n.schaerli at gmx.net
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\