Support for multiple Inheritance by classes

Ruby
21

On Mon, Nov 5, 2012 at 6:44 PM, Marc H. [email protected]
wrote:

There is one thing that is however not looked at much at
all in this discussion - less the distinction between
multiple inheritance vs. module mixins, and much more so
what the distinction class vs. module actually serves.

Because I often feel that the distinction between classes
and modules is much more arbitrary than seems to be reasonable.

The difference between class and module in Ruby is

  • classes can be instantiated, modules can’t
  • classes can be inherited (SI), modules can be included (MI)

Did I miss any? Other than that both are identical (e.g. both can be
used
as namespace). For me the more dramatic difference is actually the
first
one because despite the differences between SI and MI in Ruby it’s just
gradual (i.e. the number of items to inherit from - 1 for classes, n for
modules).

So if we assume for a moment that we agree on the most significant
difference then it follows quite naturally (for me at least) that
classes
should be used for entities, tangible things while modules should rather
be
used for capabilities (behavior). And I believe you can see that
distinction at work in the standard library: there’s Array which is a
list
of objects (entity) and Enumerable which is a set of capabilities.

But why is that behaviour contained within a module? Why
could we not assume that ALL behaviour of every object
resides in an (perhaps invisible) module?

Then we could use classes the same way as modules.

I do not understand how this follows from the premise. If all behavior
would reside in modules than classes would not contain behavior at all.
But then classes and modules could not be used the same way. What am I
missing here?

Why must there be this distinction between classes and
modules in this way?

I do not think there is a reason why the distinction “must” be there.
It’s
just what Matz designed the language to be. I think the distinction I
was
trying to make above is actually not too unreasonable. It seems so far
it
has served the language quite well so far.

Kind regards

robert

22

I found this answer quite reasonable from this book:
Learn Ruby the Hard Way .

The question of “inheritance vs. composition” comes down to an attempt
to solve the problem of reusable code. You don’t want to have duplicated
code all over your code, since that’s not clean and efficient.
Inheritance solves this problem by creating a mechanism for you to have
implied features in base classes. Composition solves this by giving you
modules and the ability to simply call functions in other classes.

If both solutions solve the problem of reuse, then which one is
appropriate in which situations? The answer is incredibly subjective,
but I’ll give you my three guidelines for when to do which:

Avoid meta-programming (multiple inheritance) at all costs, as it’s too
complex to be useful reliably. If you’re stuck with it, then be prepared
to spend time finding where everything is coming from.
Use composition to package up code into modules that is used in many
different unrelated places and situations.
Use inheritance only when there are clearly related reusable pieces of
code that fit under a single common concept, or if you have to because
of something you’re using.
However, do not be a slave to these rules. The thing to remember about
object oriented programming is that it is entirely a social convention
programmers have created to package and share code. Because it’s a
social convention, but one that’s codified in Ruby, you may be forced to
avoid these rules because of the people you work with. In that case,
find out how they use things and then just adapt to the situation.

23

If you really want a Ruby-like language with multiple
inheritance, might I suggest Python?

What I do not understand is why people suggest other languages.

It is not as simple. Python uses so many different ways,
it has a completely different philosophy, so suggesting to
use another language A because you do not like one component
in language B isn’t any real improvement.

Via modules in ruby you can get quite close to what multiple
inheritance solves.

There is no need to go to python at all.

Ruby and Python are way too similar in their ecological
niche as well.

There is one thing that is however not looked at much at
all in this discussion - less the distinction between
multiple inheritance vs. module mixins, and much more so
what the distinction class vs. module actually serves.

Because I often feel that the distinction between classes
and modules is much more arbitrary than seems to be reasonable.

You have a class Foo, and you mixin three different modules
into it. That is quite close to what multiple inheritance
does too, just not following the classical subclassing tree.

But why is that behaviour contained within a module? Why
could we not assume that ALL behaviour of every object
resides in an (perhaps invisible) module?

Then we could use classes the same way as modules.

module Foo
end

module Bar
include Foo
end

vs.

class Foo
end

class Bar < Foo
end

To me this is a distinction in Ruby that I do not really
feel is compelling at all.

I have seen people use

class Foo
module Bar
end
end

And I asked them why they did it that way, and they told
me that the toplevel class gives them more features,
namely the ability to do Foo.new, than it would by
using a module. That baffled me when I heard it.

My question thus is:

Why must there be this distinction between classes and
modules in this way?