On Fri, 29 Jul 2005, Jim Weirich wrote:

>> did you run this?  this is most defintely __not__ the diamond problem - it
>> is strictly a tree:
>
>> From my point of view, it looks like a diamond include structure, i.e.
>
>     A
>    / \
>   B   C
>    \ /
>     D
>
> Ruby does linearizes the method resolution order to D,C,B,A.

right - we are saying the same thing - the diamond is reduced to a line - ergo
no 'diamond' problem - it's avoided by requiring the programmer to order the
line via 'include'.

>> because we are walking a tree,
>> it simply does both - each 'include' statement is adding depth to
>> the search but it never becomes a complex graph that needs an
>> algorithim which resolves conflicts.
>
> Actually, there *is* an algorithm that reduces the graph to a simple linear
> search.  As modules are included, the included module's search order is
> appended to the beginning of the new search order, minus any modules that
> are already included.
>
> In fact, Ruby's MRO algorithm for modules is very similar to Python's
> (old[1]) MRO for multiple inheritance (except Ruby favors the last module
> added last and Python favors the first class added).

this is definitely more correct...

>>    http://en.wikipedia.org/wiki/Diamond_problem
>
> I found this particular entry to be less helpful than other resources.  The
> problem is rarely which method to call (which actually is not a diamond
> inheritance problem ... it can arise whenever two base classes share a
> method with a common name).  The big problem with diamond inheritance is the
> question of instance data ... do you have one or two copies?

sure... i just wast just trying to help the OP see that we currently never
actually end up with diamonds (tree does not degrade to graph) that require
ruby to resolve the search order.  currently it is entirely up to programmer
who can chose based on the order of module inclusion.  for classes it's even
simpler.  in otherwords the search order is always totally explicit and shown
in the source rather than implicit as defined by some search algorithim used
by the interpreter...  and, by extension, that making 'include' mean 'inherit'
would indeed setup a diamond issue that ruby would need to handle implicitly
(mi).  of course there are possibly other solutions...

> (and given the way Ruby handles instance variables, I find it hard to
> imagine the answer to this question would ever be two).

that would certainly be confusing...

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple.  My religion is kindness.
| --Tenzin Gyatso
===============================================================================