From: Mathieu Bouchard <matju@...>
Date: 2001-10-10T02:02:18+09:00
Subject: [ruby-talk:22322] Re: Ruby and multiple inheritance


On Sun, 7 Oct 2001, Paul Brannan wrote:
> Mathieu Bouchard wrote:
> > Say there's a diamond relationship with B<A and C<A and D<B and D<C, then
> > with classic multiple inheritance there is no way that a method in C can
> > call a method in B. with Ruby's model, you do this by calling super.

> Here's an example that illustrates our discussion on #ruby-lang.

[omitted example makes Base,Left,Right,Derived equivalent to A,B,C,D in my
example, but in both C++ and Ruby]

>        super # How can I specify that I want to call Base's foo()?
>    d = Derived.new
>    d.foo
> The difference is that in C++, the relationship looks like:
>       Base
>      /    \
>    Left  Right
>      \    /
>      Derived
> While in Ruby, it looks like:
>    Base <--- Left <--- Right <--- Derived

There's a difference between how the classes/modules are connected
together, and how the methods of the same name may be called from class to
class. From your explanation I understand that in C++ you may also call
Base from Derived in C++, in which case you'd have to trace a line
straight from Base to Derived in your graph of possible calls, because you
are able to bypass any of the two classes you derive from to get directly
to their common base class. (which is not something I remember from C++,
but I last did real C++ in 1997 or so)

> > there _is_ a well-defined way to initialize mixin data, as
> > you can deduce from the message you replied to, and from what I've said
> > above.
> Good point.  I had not considered adding an initialize() method to a 
> mixin.  However, what do I do if I want to mixin two modules, and each 
> module has an initialize method that takes a different parameter?  There 
> is no good way to initialize both mixins in this case.

What you can do is pass a Hash (of symbols to parameters) as last
parameter, in which case you reduce the possibility of collisions down to
the same level as the possibility of collisions of instance vars and
public methods.

e.g.

foo.new(42,nil,"foo",
	:my_mixin_option=>"blah",
	:other_competing_mixin_option=>[2,3,5,7])

there still has to be some kind of cooperation going on, though; the last
parameter has to be passed around, and there has to be a way to ensure the
more basic classes don't choke on that parameter, so it has to be removed
somewhere.

Another solution is to use only default initializers for mixins, and allow
post-initialization configuration.

Notice that Object#extend (and by extension, Module#extend_object) offer
strictly no way to initialize anything. (and IMHO if there is anything to
be fixed, this should be fixed at the same time as the other issue above)

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju