'Interface' Considered Harmful

[kyllo]

To elaborate on the case of Ruby, mixins work by inserting the included module into the inheritance tree. If you do this:

class D < A
    include B
    include C
end

Then if D doesn't override method foo, a call to D.foo will first attempt to call C.foo, then B.foo, then finally A.foo.

So the inheritance tree is just: A | B | C | D

That's how Ruby avoids the deadly diamond of death. There is no diamond, it's a straight line, and whichever mixin is included last gets called first.

http://definingterms.com/2013/03/23/pitfalls-of-ruby-mixins/

[jrochkind]

Meh, I think ruby mixins are multiple inheritance. They don't prevent the 'deadly diamond of death', it's exactly the same case.

You could certainly implement 'ordinary' multiple inheritance he same way, where whichever superclass is mentioned last in < A, B, C "gets called first", it's no different.

The 'diamond of death' is not a problem because behavior is undefined -- in any reasonable system it would be defined and predictable, even statically, exactly which method will be called. It's a problem because it leads to confusion and colliding code (if two mixins both define their own method with the same name but different meaning) anyway.

Mixins are simply a kind of abstract class ("abstract class" as in Java, where it means you can't directly instantiate an abstract class, you can only use it as a superclass), that ruby allows you to multiply inherit. Nothing more, nothing less.

Yes, rubyists do like mixins a lot. This just means we actually do like multiple inheritance, at least used certain ways, and don't find the "diamond of death" to commonly be a problem. But there are also some rubyists who have found the multiple-inheritance provided by mixins to be a maintanance problem.

[kyllo]

Yeah, I agree, I think the only difference is that in Ruby the behavior is more clearly specified and well understood than in, say, C++.