I'm UK-based, 37 years old, male programmer. Most of my practical experience is in BCPL, C and C++, but I've also used Java and Smalltalk. I admire Eiffel and the Lisps, and Cecil Language.
See www.bhresearch.co.uk 
for more info about me (and a free Java applet). Send email to mailto:brangdon@cix.co.uk. My Usenet posting are From: scorp@btinternet.com.
www.bhresearch.co.uk
I was one of the Visitors In Ninety Seven.
I no longer visit this Wiki very often, so I may miss comments on other pages or even on this page.
The reason is not so much the signal to noise ratio as the sheer volume. There is too much for me to keep up. Keep up with what? Conversations, I suppose. It's more complex than just blaming thread mode, though. I believe any community technology has an ideal size and the Wiki community has got too big for the way it was working a few years back.
"Weave a circle round him thrice, And close your eyes with holy dread, For he on honey dew hath fed And drunk the milk of Paradise."
(Archived text from Mis Using Multiple Inheritance)
Shape abstract class, abstract (pure virtual, for C++ folks) method bounce(), with subclasses Sphere, Cube, Pyramid. Obviously for each one the bounce() method does something slightly different.
Texture abstract class, again, abstract method bounce(), with subclasses Rubbery, Sticky, Fuzzy, again, clearly different implementations of bounce().
So now I want each kind of shape with each kind of texture:
Rubbery''''''Sphere Sticky''''''Sphere Fuzzy''''''Sphere
Rubbery''''''Cube Sticky''''''Cube Fuzzy''''''Cube
Rubbery''''''Pyramid Sticky''''''Pyramid Fuzzy''''''Pyramid
I'm sure you can see where this is going....
No, not really. You have to rename bounce along one or both paths, of course, but a decent language (eg Eiffel) will let you do that without changing either base class's source code. If this kind of thing is what's bothering you, perhaps you've never used a language with decent support for multiple inheritance? --
Renaming methods is not a huge difficulty. The problem illustrated with the design above is the rapidly growing number of classes as new shapes and textures are added to the system. It would be better to model shapes and textures separately and relate them by association, rather than inheritance. E.g. "a shape has a texture" instead of
"a shape is textured". --
Steven mentioned "bounce", and I think renaming was his point. Your point seems to be that the example is contrived, which he conceded in advance. It seems to me we could get rid of both inheritance axis and say a graphical object has a shape and has a texture. In other words, multiple inheritance is bad in the same ways that single inheritance is bad. --
My point was that naive multiple inheritance leads to a rapidly growing number of classes (as Steven Newton also states below). I am also not
saying that multiple inheritance is bad, or misused in the same ways as single inheritance. The problem with naive uses of multiple inheritance is that inheritance is used to combine behaviours
rather than interfaces.
If behaviours are combined using delegation, the problem outlined does not raise its head.
See original on c2.com