Furthermore look at your example. You offer 4 basic geometric types. But would you even really want to model them with an isa arrangement? I don't know about you, but when I think of modelling a square, most of the implementations that I would start with don't turn into good implementations of a parallelogram or rhombus. Unless, of course, I started knowing that I wanted parallelograms...

Yes, I want to model them in an isa arrangement. I wasn't thinking about "modelling" a square. I was thinking about a property system. A square has all the properties of a rectangle. A square has all the properties of a rhombus. Both the rectangle and the rhombus have all the properties of a parallelogram. What is more natural than multiple inheritance to express these facts? See also my response to flying moose.

Therefore I'm inclined towards merlyn's view. If you can solve your problem using single inheritance, do so.

While I agree with the latter, I don't think that's what Merlyn said. What he said was:

If the answer to a question is "multiple inheritance", you've probably asked the wrong question.

which to me means "never use multiple inheritance".

The following type of discussion is rather common (and a variation of it happened above):
Question: How do I set up design X?
Answer: Use multiple inheritance.
Better Question: How can I modify design X to solve my original problem in a simple way with single inheritance?

What merlyn said seems to be an empirical statement that discussions like that constitute most of the cases where the answer is, "Use multiple inheritance." Therefore if that is your answer, you've probably asked the wrong question.

Incidentally I'm unclear on how you got "never" out of "probably..wrong".

And when you learn another language, you can design the same way secure in the knowledge that single inheritance always is present, and its behaviour doesn't tend to change that much between languages so you have less relearning to do.

That I find a weak argument. I'm not shying away from hashes because normal arrays are always present in other languages and hashes may not. Besides, there are languages that don't have support for even single inheritance (for the mere fact they don't have native OO support).

I should point out that when working in languages without native OO, it is often possible to write your own OO framework. (In fact many people do it by accident.) It is easier to roll a single-inheritance scheme than a multiple-inheritance one. It is also easier to optimize single-inheritance than multiple. So if you are caught without native OO but want OO, then again it is easier to plan to design for single-inheritance.

But your basic point is true. It makes no sense to avoid features in language X just because language Y does not possess them.

However for people who have to move around between languages a lot, it does make sense to try to work with concepts that stay common. So you might add a library to your C programs giving you ready access to hashes and regular expressions, and then choose to stay away from multiple inheritance in other languages because its presence and details vary so much between Perl, Java, C++ and Python. That will limit your confusion.

If you don't need to balance multiple languages, then this issue has no bearing.

Once you decide to use @ISA, you limit choices on how to model things. Your implementation of a Square has to be the same as your implementation of a Parallelogram. Which is an inconvenient implementation of a Square.

Why does the implementation of a square to be the same as one of a parallologram? That's not why how one typically uses inheritance. An implementation of a base class is different than one of a super class - otherwise, there would not be a point in using inheritance. A base class and a super class typically share part of their implementation - and sometimes everything of a super class is inherited by a base class; that is, the base class doesn't redefine any method, or mask any attribute, of the super class.

As for a parallelogram being inconvenient as an implementation of a square, I'm kind of flabbergasted. I cannot think of any property a parallelogram has, that a square hasn't.

Abigail

We are obviously talking past each other.

When I said "implementation of a Square" I meant the data structure that you use. An implementation of a Parallelogram needs more information than an implementation of a Square. Which means that you wind up carrying around extra fields. Furthermore while you can inherit methods for calculating things like the area, it is more efficient to calculate those for a Square directly.

There is nothing wrong with inheriting an implementation of a Parallelogram. If you have it. But if you really need a Square, it is far simpler and more efficient to implement that directly rather than to deal with the generalization that is a Parallelogram.

However that point is relatively unimportant (and obviously has nothing to do with multiple inheritance) compared to the others that I had made.