Re: inheritance concept in ruby

Hi!

[e-mail] escreveu:

> On Mon, 15 Jan 2007, Helder Ribeiro wrote:
>
> > 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.
>
> I'm not sure you really mean class method here.  What you're saying is
> true of any time you send a message to an object -- that is, it looks
> in its class, then the modules, etc.

Yes, i meant any method call. But I haven't found this lookup order
stated in its full anywhere else. The part after the "*and*" is what I
inferred from what the PickAxe says about the other cases (the quote is
in this thread somewhere).

> >
> > 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?
>
> No, the lookup order principle still keeps it uniform.  It's useful to
> think of it from the object's point of view.  You send a message to an
> object, and it goes on a search for a method with a corresponding
> name.  This search always takes place along an unambiguous, one-track
> path.  The object doesn't see trees or forks in the road.

Yes, that's precisely what I said. I'll rephrase it:

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?"

> 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.

> > 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.

>
> > 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?
>
> 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)?

Cheers,

Helder