So, I’m afraid I’m joining the ruby cult. Or at least learning ruby.
I like a lot of things about it (so nice to work with a really object oriented language, where the community writes really object oriented code), and don’t like some things about it (still suspicious of ‘duck typing’, the community doens’t seem to write very good documentation).
But my question is: How are “mix-ins” any different than multiple inheritance? What am I missing? mix-ins as a feature seem to be exactly no more and no less than multiple inheritance. Is it just the convention for how to use them (just a few methods focused on a particular function) that makes them “mix-ins”? Like, mix-ins are mult inheritance used in a certain way? Is there something I’m missing?
Bibliographic Wilderness 
Well the big difference is multiple inheritance lets you extend multiple classes while the mix-in mechanism lets you include a Module(s) in a class, but not another class.
In practice it’s not that big a difference. Except that modules don’t have class variables or instance variables of thier own.
Different languages have different ways to handle the multiple inheritance problem. Java, for example, uses interfaces. Modules/mix-ins are Ruby’s solution. So yes, that’s pretty much what they’re about.
Mix-ins are classes that you would never instantiate on their own — they only exist to add functionality to an existing class, and they live outside the heirarchy of classes (so you can add them to different classes without those classes being related to each other at all, and mixins can never have a superclass themselves). With MI the child class inherits the class methods of all the parents, whereas with mixins, you can only access the class methods of the mixin from the mixin itself. Whew!
I think this explanation of MI as nouns and mixins as adjectives is pretty good.
Well, Java interfaces don’t let you actually inherit implementation (code), they only define interface (aka ‘type’). So that’s one way they are different than mult inher, although yeah, they’re meant to get at the same general problem space.
But mix-in modules DO let you inherit implementation/code. So they’re not just addressing the same ‘problem’, they seemed to me to be the same solution! So why give them a different name?
It’s true that only CERTAIN class-like objects, those defined as Modules, can be multiply-inherited, rather than any arbitrary class. That’s a difference, but I’m not sure what the point of that is.
Except someone on #ruby-lang today said that one difference is that you can’t sub-class a Module, Modules don’t get any parents of their own in the inheritance hiearchy. So that’s a real difference, a restriction on what Module mix-in can do vs. Mult. inher. I guess that does save you a lot of potential headache inducing complexity (as well as prevent some neat things, naturally!). I’ve never actually spent much time with a language that really does have Mult. inher., so it’s hard for me to have a sense of how much benefit this feature gives you.
All in all, after some recent time exploring different new languages these days, I’m *most* impressed by ‘Traits’ as implemented in this Perl module. Maybe later I’ll write a post about them. (They’re still not enough make me happy about Perl! — although if the Perl community actually adopted them in it’s shared code, it would go a long way)