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 CecilLanguage.

See  http://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.

http://www.bhresearch.co.uk/Art/DrhFeed.jpg

I was one of the VisitorsInNinetySeven.
----
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."
-----
CategoryHomePage
----

(Archived text from MisUsingMultipleInheritance)

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....

-- StevenNewton

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 StevenNewton 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.''
----