matz / zetabits.com (Yukihiro Matsumoto) writes:

> Mix-in is a restricted MI.  You can't have shared superclass like
> 
>      A
>     / \
>    B   C
>     \ /
>      D
> 
> which often cause problems.  Since mix-in is a subset, you can do
> mix-in by MI, of course.

The other difference is that a mixin is not a class, but a module. As
such, it does not have its own state (although it can add to the state 
of classes that mix it in).

If you try to generate the diamond inheritance pattern above using
mixins:

     module Base
     end

     module M1
       include Base
     end

     module M2
       include Base
     end

     class Main
       include M1
       include M2
     end

You actually end up with a linear chain of pseudo superclasses:

     Main -> M2 -> M1 -> Base

All the state is held in instance variables within class Main, and
messages sent to objects of class Main are resolved by methods in
Main, M2, M1, and Base, in that order.

This simple scheme makes mixins less ambiguous that MI. However, there 
are still problems, particularly if method names clash, or if a mixin
uses instance variable names that clash with those in other mixins or
with the including class.


Regards


Dave