>Now, how many instances of A are in d? Two (one for B, one for C) or 
>one? If one, what is the value of @var? You avoid such problems with 
>mixins (modules).

In your example (and my imaginary Ruby 2.1), @var is not defined. D descends directly from Object, not A, B, or C. As such, D.new calls D#initialize, which is defined on Object as a method with no parameters. A#initialize, B#initialize, and C#initialize never get included in the D class, as D's superclass, Object, already defines it.

Gimme another! This is fun.

Devin
*sigh* Years spent in school and at work playing the human computer... I actually find it _fun_ now...

----
twifkak / comcast.net schrieb:
>> Then you will have complex network of classes instead of simple
>> tree structure, sharing code with modules.
> 
> How does a complex network of classes differ from a complex network
> of mixins? The main difference that I see is, as Ara pointed out,
> #is_a?. But I could be missing something. I usually am.

For me, the main difference between modules and classes is that classes 
"define" state (instance variables), not only behaviour (methods). One 
classic problem with multiple inheritence is the so called diamond:

   class A
     def initialize(val)
       @var = val
     end
   end

   class B
     include A
     def initialize
       super(5)
     end
   end

   class C
     include A
     def initialize
       super(42)
     end
   end

   class D
     include B
     include C
   end

   d = D.new

Now, how many instances of A are in d? Two (one for B, one for C) or 
one? If one, what is the value of @var? You avoid such problems with 
mixins (modules).

Regards,
Pit