matz / ruby-lang.org (Yukihiro Matsumoto) wrote in message news:<1085543091.097337.6604.nullmailer / picachu.netlab.jp>...
> Mix-in is no better than multiple inheritance, because mix-in is just a
> usage of multiple inheritance.  You can do mix-in by multiple
> inheritance.  Ruby forces mix-in to make it hard to "abuse" multiple
> inheritance.

The difference for me has been mainly conceptual.  I consider mixins
to be:

* Primarily functional.  You're mixing in functions.
* Stateless.  There are no class-level variables with mixins.
* Mixins anticipate and make use of methods in some future class that
mixes them in.

As assertions, these are patently untrue; you can end up mixing in
class-level variables in Ruby, and the mixed in methods don't ever
have to access any external methods.  However, these are the
characteristics that I generally associate with mixins.

Inheritance, multiple or single, has different general
characteristics:

* Stateful.  You are inheriting not only behavior, but state.
* Ignorance on the inheritee of the inheritor.

In Ruby, there is nothing that you can do with one that you can't do
with the other -- except for multiplicity -- so there is no practical
difference.  I believe that the conceptual difference is useful,
though.

--- SER