On 1/11/07, Helder Ribeiro <helder / gmail.com> wrote:

> I'm also new to Ruby and I've never used anything with multiple
> inheritance. This code is enlightening but I can't see how this is
> different from multiple inheritance in practice except that AlsoUseless
> is not a class and you don't use the '<' sign with it.

The real complication with multiple inheritance is that you end up
inheriting the ancestors of both parent classes.

When you use a mixin, the additional methods are tacked on to a class
in the heirarchy, rather than creating another set of ancestors.

Since modules live outside of the tree of inheritance, they can be
used to provide functionality without complicating the ancestry chain.

See Comparable and Enumerable for excellent and practical uses of modules.

> In which cases do the two scenarious (M.I. and mixins) cause different
> behaviors? Is it only related to member visibility? If yes, how
> exactly?

if:

A < B < C

and module D is mixed into C, there is still a single path back to A.

Had we used multiple inheritence (if it were possible), perhaps

F < E < D

so now, C has two distinct roots, A and F.

Now imagine circular dependencies and other complications.  Scary! :)

So modules allow you to avoid the verbosity of interfaces without
complicating the chain of ancestors.