What's so special about operators, built-in classes and modules?

ruby-talk
1

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