On 14.06.2008 16:09, Old Echo wrote:

> Thank you for your responses. This is more of a philosophical rather 
> than a practical question -- I'm not facing this situation in any 
> application that I'm trying to write.
> 
> Background: I used to work at a company that was an all-Java shop where 
> I would occasionally debate the merits of Ruby vs. Java (dynamic vs. 
> static, etc etc etc) with one of my co-workers who is a big Java guy. 
> Somehow the topic of multiple inheritance came up, and one of the "shoot 
> Ruby down" arguments was that because of this "last-one-in" wins 
> behavior, Ruby couldn't really help solve the issues that come up when 
> trying to do multiple inheritance. Of course, it was pointed out that 
> Java doesn't really have a good way to do this either, but I left the 
> conversation feeling like something was amiss with the argument.

Well, first of all: as has been demonstrated, there *are* in fact ways 
to deal with this situation in Ruby.  But: IMHO it is not a too good 
design to inherit from two classes that share a common part in their 
signatures (public interface).  Granted, there are some methods with 
obvious names (like "size", "length") that are likely to be present in 
multiple classes and you cannot completely prevent this situation.  But 
resolving this is ugly - no matter what programming language you use. 
Even in Eiffel - where you have sophisticated means to resolve such 
situations and the language is very strict about not allowing 
ambiguities - I would find a situation ugly where two classes that share 
common methods would be publicly inherited (i.e. "is a" relationship is 
visible to clients of the class).

> But again, these are really just philosophical ponderings more than 
> anything else. Good discussion, though! I'd love to hear more from 
> anyone who has thoughts on this.

Yes, it's good to think about these topics from time to time!  And it 
reminds me that I have to reread Bertrand Meyer's book OOSE again.

Kind regards

	robert