Dave Thomas  <Dave / Thomases.com> wrote:
>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

So in the case of method name or
instance name clashes, the earlier entries in this sequence
take priority?

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

I'm wondering about a slightly more complex example - where Main has a
super class that has its own modules.  How do name clashes
resolve in that case?


Thanks,

-= Josh