On Sun, 24 Aug 2003, Yukihiro Matsumoto wrote:

> The primary inheritance is inheritance to form class tree.  It's
> inheritance in single inheritance.  The auxiliary inheritance is what
> we call mix-in.  Despite my previous statement, the auxiliary
> inheritance can be "is-a" relation. This combination is indeed a
> restricted multiple inheritance.  By this restriction, we won't have
> diamond inheritance problem,

module A; end
module B; include A; end
module C; include A; end
class D; include C,B; end

This is a diamond inheritance pattern.

Both Ruby and LISP enforce what is called "virtual inheritance" by making
the instance variables uniquely identified by a [receiver,symbol] pair, so
that two perspectives D<C<A and D<B<A by which A may be reached through D,
still access the same data, therefore there is no difference between those
two perspectives, therefore it makes sense to remove the duplication and
have A's methods appear once in the call chain.

Note that this way to deal with inheritance occurs both in a Class/Module
system and a Class-only system.

In the diamond inheritance problem, I can't see which part is more dealt
with, solved, or avoided, in your system, than in LISP's system. I see no
difference.

> nor confusion by complicated class relation network,

Instead you can have confusion by complicated module relation network, and
then confusion by not knowing which construct to choose.

> I think this distinction help good design of class hierarchy.

I can't really confirm that.

> So, by removing this restriction, what can we buy?  No restriction?
> Fine, but it's not what _I_ want to buy.  What else?

I have listed a few reasons in [ruby-core:1448]. However I can't dig you
magically powerful arguments.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju