Yes, there was once a form of Multiple Inheritance In Smalltalk.
It was even used from time to time, and could probably still be made work. It used basic capabilities defined in standard Smalltalk, and thus requires no special magic (no VM or compiler changes are needed, for example).
The basic idea was to fake multiple superclasses by judicious use of Does Not Understand. The good news was that it worked (and can still be made to work once you know the mechanism). The bad news was that it was extremely slow, because every message send outside the "primary" (actual) superclass chain had to trap through DNU.
Once we learned that Delegation Is Inheritance (see OOPSLA Proceedings from 1987), the need for this was dramatically reduced.
When used within a Liskov type hierarchy and properly resolved, Multiple Inheritance is still a good thing. For example, consider the design of class "Matrix". It has rows, columns, elements, and can be enumerated and pivoted. Thus, it certainly wants to behave like a collection. It also participates in arithmetic operations ... instances respond to "+", "-", "=", and so on (ignoring dot- and cross- products for the time being). Another example is "Complex", which wants to act like both an Association and a Magnitude.
These are cases where Multiple Inheritance, in my opinion, really is the best and most supportable solution. Yes, it can be simulated through delegation or protocol-copying. But the basic concept is still Multiple Inheritance.
If anyone really wants to know, I can dig up the old Smalltalk source for Multiple Inheritance In Smalltalk -- I have it in hard-copy.
Hmmm.. I'll bet a prototype-based language like Java Script or Self Language could do this better.
Yes, perhaps -- though I'm dubious about Java Script. Self Language and Lisp Language both do fine in this regard, bearing in mind their other limitations. -- Tom Stambaugh
Smalltalk-80 actually had a tool that generated a multiply-inheriting class by generating the delegation mechanisms: you specified the superclasses, it made an instance variable to hold an instance of each one, generated an #initialize method to create the instances, generated a delegation method for every method found in (or inherited by) exactly one of the super classes, and complained about methods defined by more than one superclass (or generated an empty method body for you to resolve, or something like that). I seem to remember Alan Borning being the author. Like Inheritance itself, Multiple Inheritance is both a design concept and an implementation concept, and the two are independent: you can have a non-MI implementation of an MI design and an MI implementation of a non-MI design (for instance, using private base classes in C++ for implementation convenience, as used extensively in the Rogue Wave Tools.h++ collection libarary.) -- Mitchell Model
See also Is Smalltalk Complete? for more MI discussion. And Multiple Inheritance Is Not Evil for staunch defence.
See original on c2.com 