Hi,

In message "Re: What's so special about operators, built-in classes and modules?"
    on Thu, 28 Jul 2005 13:14:49 +0900, Devin Mullins <twifkak / comcast.net> writes:

|>If we allow "include" to take classes, it's a plain multiple
|>inheritance.
|>
|If that were true, then your previous statement wouldn't be true:
|"Besides that, there's no diamond inheritance in Mixin inheritance."

Would it?

|If we make the include method act the same on Classes as it does on 
|Modules (that is, to call #append_features, which, in turn, adds the 
|constants, methods, and module variables of the included class to the 
|receiving class), then that's just Mixin inheritance on Class objects.

I'm sorry that I don't get it.  We call it mixin inheritance because
mixin (modules) have some restrictions over classes:

  * no superclass (although including other mixin is allowed)
  * no instance

which make mixin inheritance as it is.  Allowing "include" method to
include classes removes above restrictions.  Then that's no different
from multiple inheritance, in my opinion.

I know there's some drawbacks in the current implementation of Ruby's
mixin inheritance, when a module is included repeatedly.  I am willing
to fix it.  I'm seeking the best way to fix.

Besides all of them, I don't understand why this issue arise again and
again.  _I_ encourage mixin inheritance.  It is powerful enough to
solve the problem in single inheritance (sharing code between classes
beyond inheritance line, without copy&paste).  It is much simpler and
easier to use than multiple inheritance.  Why people want "real"
multiple inheritance by unifying classes and modules, when Ruby's
mixin inheritance works quite well?  Why people want unnecessary
complexity?  Just because other languages do?  I'm curious.

Interestingly, a few have complained for the lack of goto in
Ruby. Goto is much more powerful control structure than while, break,
next, etc.  We can construct others using goto.  I wander why no one
propose to unify them.  ...No,  Don't.  I will refuse.

							matz.