From: dblack@...
Date: 2007-01-20T10:00:54+09:00
Subject: Re: inheritance concept in ruby

Hi --

On Wed, 17 Jan 2007, Helder Ribeiro wrote:

> I see no difference between having Modules or having Multiple
> Inheritance (although I guess there must be and the difference between
> them is the answer I'm trying to find). The problem Gregory Brown
> pointed out with M.I. I have claimed to exist still with Modules.
> ["A->B->C can be the class hierarchy while ?->D->C and ?->E->C are
> module hierarchies"; discussion above in this thread].
>
> The only difference I could think of is that, when you have A->C and
> B->C ("->" here meaning "is inherited by" or "is mixed into") and both
> have a method with the same name, the conflict you would have with A
> and B being classes - since they have equal rank in the hierarchy -
> doesn't exist when B is a module, because modules have lower priority.
>
> But this is an artificial difference, because you can define a lookup
> order to solve this conflict without the need for Modules. So the
> question is
>
> "since Ruby already has a well-defined lookup order that takes care of
> conflicts in class/module hierarchies, couldn't you have a similarly
> well-defined lookup order for Multiple Inheritance and do away with
> Modules altogether?"

Yes, almost certainly.  There was a big push for class/module by
Mathieu Bouchard, a couple of years ago.  The discussion was mostly on
ruby-core, and would be in the archives.

>> There's still the possibility of name collision with mixins, but there
>> are (to my knowledge) no special cases, no need for tie-breaking rules
>> -- because the rules that are there in the first place make a tie
>> impossible.
>
> Don't understand what you're saying. There is, indeed, no need for
> tie-breaking rules if you have lookup order rules (i'm assuming those
> are what you mean by "the rules that are there"). It happens that they
> are the same, though, you're just giving them different names.

I'm probably not expressing the tree (or lack thereof) thing and the
rules thing very clearly.  I guess what I'm saying is: there *is* a
rule, so while there would certainly be an issue to solve if there
weren't, there is, so there isn't :-)

>>> And yet, this is a problem only when there is name collision which, as
>>> you said, is a small case and mostly due to code smell or unavoidable
>>> complexity.
>>>
>>> What I don't see is what exactly having separate class/module
>>> hierarchies buys you. You ensure a simple tree structure for the class
>>> inheritance graph, but you (apparently) don't have that for the module
>>> graph and they are both connected. Doesn't that blow the idea of tree
>>> for the former?
>>
>> Maybe, but in the end it's not really a tree model; it's a path model.
>> When you include modules in classes, you're inserting them in the
>> method look-up path of instances of those classes.
>
> It is a tree model (if you take only class hierarchy; with modules it's
> a network). The method lookup path is a path in the tree from the class
> of the object whose method was called (the class is a node) to the
> superclass where the method is defined (also a node). "The object
> doesn't see (...) forks in the road" because, in a tree, there is
> always only one choice of parent node.

Like I said, I'm taking an object's-eye view.  Every path is a tree, I
suppose, in the sense that one can deviate from it :-)  I know what
you mean, though.

>> The thing I like about modules is that I find the model a suggestive
>> way of thinking about domain modeling.  I like having both a noun-like
>> thing (classes) and an adjective-like thing (modules).
>> Then again,
>> all of this is purely in the context of Ruby; I don't inherently like
>> one or the other more.
>
> So the difference is only in the way you think about those two things
> (classes and modules)? Or do they have some difference in their
> inheritance behavior that makes you think multiple inheritance would be
> unsuitable for what you do (I know nothing about domain modeling)?

I don't think anyone came up with a strictly technical, bullet-proof
objection to class/module unification when Mathieu was advocating it.
Basically, if all the modules in the lookup-path were, instead,
classes, I don't think anything we can do now would be impossible
(assuming the lookup rules were preserved).  In that sense the
presence of the difference is more a matter of semantic enrichment
than technical extension.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)