Multiple Inheritance In Smalltalk

Yes, there was once a form of MultipleInheritanceInSmalltalk.

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 DoesNotUnderstand. 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 DelegationIsInheritance (see OOPSLA Proceedings from 1987), the need for this was dramatically reduced.

When used within a Liskov type hierarchy and properly resolved, MultipleInheritance 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 MultipleInheritance, 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 MultipleInheritance.

If anyone really wants to know, I can dig up the old Smalltalk source for MultipleInheritanceInSmalltalk -- I have it in hard-copy.

-- TomStambaugh

Hmmm.. I'll bet a prototype-based language like JavaScript or SelfLanguage could do this better.

Yes, perhaps -- though I'm dubious about JavaScript. SelfLanguage and LispLanguage both do fine in this regard, bearing in mind their other limitations. -- TomStambaugh

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 AlanBorning? 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.) -- MitchellModel

See also IsSmalltalkComplete? for more MI discussion. And MultipleInheritanceIsNotEvil for staunch defence.