What you have when a class has more than one direct superclass. Some OO languages have Multiple Inheritance (for instance: Cee Plus Plus, Common Lisp, Python Language, Perl Language); some don't (for instance: Smalltalk Language, Modula Three, Java Language). Java does have a sort of half-way house called "interfaces", providing multiple inheritance of interface but not of implementation. (When I switched from C++ to Java I got blesses on my fingas.)
Some people like Multiple Inheritance , some don't. See Multiple Inheritance Is Not Evil, and maybe also Multiple Inheritance In Smalltalk.
Not to be confused with Multiple Dispatch, which is what happens when method dispatch looks at the (dynamic) type of more than one object.
(And which people disagree on just as much as they do about Multiple Inheritance .)
Surely no one thinks Multiple Dispatch is evil?
The classic first complaint about MI is inherited method clash. And just why can't people establish that inherited implementation clashes are illegal, and otherwise allow MI? That would have the side effect of preventing diamond-shaped hierarchies for all but the most abstract of classes. Essentially, it makes the practical issues disappear. This still leaves the damage you can cause with Taxo Mania, but that is a Bad Programmer problem, not a Bad Feature problem. -- Ian Kjos
There is no method clash. In Common Lisp, for example, each class has a precedence list, which is used to determine all applicable methods at time of dispatch. This problem is a myth, and only exists in some (poorly, in my opinion) designed languages.
Please don't forget Eiffel Language. It does Multiple Inheritance right.
Multiple Inheritance of implementation allows for Mix Ins.
Some of us Relational Weenies see "sets" when we see multiple inheritance. Multiple inheritance is an oxymoron IMO because if you have multiple parents, then it is not really a true hierarchy any more. It is my belief that Limits Of Hierarchies will eventually lead to sets as real-world complexity creeps into a project/system, which will lead to relational-like technology. Perhaps this is an All Roads Lead To Rome sin, but that is how I see it. Hierarchies are easy to relate to (initially), but don't scale well over time (changes) or project size increases. -t
Yes, classes are sets of functions. How is that comparable to relational where there are sets of data?
Classes are sets of objects, not sets of functions. Multiple Inheritance reflects the fact that sets may intersect, and is often an ugly kludge.
Why must it be a hierarchy? Why not a simple directed graph?
It can be a graph. With multiple inheritance, it is a "multiarchy" instead of a hierarchy. The issue that must be resolved, however, is the order in which conflicts are resolved. If a given class inherits from both classA and classB, and both classA and classB define someMethod, then the order determines whether classA.someMethod or classB.someMethod is actually selected. Similarly, if either method includes a call to "super", or its equivalent, then the order determines which ancestor's method is selected. The "conflict" isn't a problem, per se. The multiple-inheritance mechanism simply needs to provide a mechanism for resolving the choice.
See also: Callinga Spadea Spade
See original on c2.com 