Re: inheritance concept in ruby

Gregory Brown wrote:
> On 1/16/07, Helder Ribeiro <[e-mail]> wrote:

> > 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).
>
> Perhaps we need to document this better.  I'm not sure where the best
> place would be, though.

Yes, definetely. The only thing I managed to dig on this was this
thread from way back that I don't even know if still fits (and haven't
read in full to know if it the guy ended up getting a well-defined
method resolution order).
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/dbe4fc8bea8ef1f8/#

> > "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?"
>
> Probably.  But the question is, why would you want to do this?  I
> suppose what would be important to know is whether this interest in
> the system is of theoretical or practical grounds for you.

It is of theoretical grounds. The question I posed with "do away with
modules" is actually a way to understand some theoretical difference
that there must exist between MI and Modules, not that I actually think
Modules should be done away with. It is a sort of proof by absurd. The
discussion so far has been sort of like:

"modules are needed to avoid a set X of problems with MI";
"but modules have those same problems in X";
"but in modules you solve problems in X with Y";
"but in MI you can solve those same problems in X with Y"

So the first sentence is false, at least for the problems in X (name
conflicts in multiple parent hierarchies). You can solve them both in
MI and Modules with Y (a well-defined resolution order).

Unless, of course, there is some fundamental difference that makes
possible the existence of a well-defined resolution order (Y) for
Modules but not for MI. That's what I'm trying to find out, and it
there *must* be some such difference, otherwise why would people have
come up with Modules in the first place? Only because, although having
the same problems, it inspires a different mindset in programmers so
that they are less prone to running into those problems?

> If it is
> of theoretical grounds, these are all valid questions, but I do think
> they'd end up somewhere around the 'this is how matz implemented them,
> so unless something Really Wrong with them can be shown, they're here
> to stay' conclusion.

Yeah, I'm not saying it's wrong and should be changed. I'm saying there
must be a reason for it and I'm trying to understand Ruby better by
understanding that.
>
> Tie breaking rules are necessary when you end up with cycles in the graph.
> The MRO for Python 2.3 is pretty straightforward, mostly because it
> fails if this occurs (preventing the need for complex tie breaking
> rules).
>
> http://www.python.org/download/releases/2.3/mro/

Very good reference! Helped a lot!

> With mixins however, there is no situation where this would occur,
> which is one of it's strengths.

But cycles can't exist in either. I think the problems the reference
addresses are more subtle (I've read about monotonicity so far but
there's also one about "local precedence ordering") and, while the
*class* hierarchy doesn't have them (single inheritance), I'm not sure
if a hierarchy of modules alone can't show them.

>
> This is mostly a style thing.
>
> So just like using any concept to organize your code, on it's own,
> there is little technical difference.
> But it is very powerful when you use the concepts right.  You say,
> hmm... I'm looking at a relationship in which this chunk of code
> describes the kinds of things you can do with an object if it meets
> certain criteria, that sounds like a module would make sense.  Or,
> this object embodies something rather concrete with unique behaviors,
> perhaps a class would be appropriate.
>
> Sometimes this changes as you go through your development process.
> Sometimes you realize you only needed a module and you used a class.
> Or sometimes the opposite happens.  So it's not like Ruby is forcing
> your hand to do one or the other.  The relative similarities between
> the two make it somewhat easy to refactor from one to another without
> changing much.

Very nice. I think it's mostly a style thing than, as you said. The
Classes/Moudles thing is probably a good mind frame to think in.

And the theoretical differences must be so subtle that in the end it
probably wouldn't influence much when you're programming anyway.

Besides that, I've nagged for long enough already, and it's kinda
fallen out of the scope of a list discussion. If I'm really serious
about the details I'd probably have to go through some books on
compilers, grammars and stuff.

It'd be good to have some greater understanding of the Ruby MRO though,
leaving aside the Modules/MI quest-for-difference a little.

Perhaps I'll dig it up a bit more and write something on it to share
with people. Anyone interested in helping out (in the digging and/or in
the writing)?? =)

Anyway, thanks a lot Greg and everyone. It's been a great first
incursion into ruby-talk and I'm positively impressed =)

Cheers,

Helder