From: Helder Ribeiro <helder@...>
Date: 2007-01-15T11:55:06+09:00
Subject: Re: inheritance concept in ruby

Gregory Brown wrote:
> On 1/12/07, Helder Ribeiro <helder@gmail.com> wrote:
>
> (...) the issue is rarely with immediate dependencies, but dependency chains.
>
> I.e., with mixins,
>
> If I have A->B->C and C mixes in D, then E
>
> the lookup is C,E,D,B,A
>
> which logically is quick intuitive if you think about it.
>
> If I have A->B->C
>
> and  ?->D->C
>
> and
>
> ?->E->C
>
> Those two question marks represent two independent dependency chains
> that you cannot be sure what they implement without knowing the
> ancestors of each.

That's true. It made me think of one thing though. The PickAxe, at
least in that part I quoted, is silent about lookup order when mixed-in
modules include modules. If you extend the reasoning, though, you can
say that when a method call is made inside a class method, Ruby first
checks for methods in that class, then in the modules it includes (so
far nothing new) *and*, inside those modules, first for methods they
implement themselves, and then for methods defined in modules mixed
into them.

So how would this be different from the scenario you suggested with
multiple inheritance? You can get an exactly analog problem, where the
conflict might lie not in immediate dependencies, but in dependency
chains. A->B->C can be the class hierarchy while ?->D->C and ?->E->C
are module hierarchies.

I didn't understand what you meant by "you cannot be sure what they
implement without knowing the ancestors of each". Isn't that true even
for A->B->C alone? You can't know what C implements unless you know B
and C.

And if the problem is only lookup order, separating class hierarchy
from module hierarchy makes it easier only in the case where you have
*one* class hierarchy (A->B->C) and *one* module hierarchy (F->D->C),
because it is given that you choose first from the class hierarchy. For
cases of 3+ you still have the same problems, right?

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?

The only thing holding me from saying "it's a tree, *connected* to a
general network, thus it's all a big network" is that the connection
seems to be unidirectional (modules can't have classes 'mixed in' or
inherit from them, I suppose). Is there some theoretical result that
bases itself on this (or some other thing, I dunno) to say that there
is a clear distinction between the M.I. model and the "tree +
pan-inheritance-modules"?

Furthermore, if both models are almost (or perhaps completely)
equivalent *and* the only problem is with the limited case of name
collision and that can be solved with lookup rules, where is the source
of contention? Why would people favor one over the other?

Sorry for the verbosity and thanks for the nice conversation.

Cheers,

Helder