Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!att!dptg!pegasus!hansen
From: hansen@pegasus.ATT.COM (Tony L. Hansen)
Newsgroups: comp.object
Subject: Re: How to use Inheritance instead of nesting
Summary: MI is not necessarily bad
Keywords: C++, multiple inheritance
Message-ID: <4975@pegasus.ATT.COM>
Date: 16 Aug 90 20:39:51 GMT
References: <13647@shlump.nac.dec.com> <4800097@m.cs.uiuc.edu> <243@cadlab.sublink.ORG>
Reply-To: hansen@pegasus.ATT.COM (Tony L. Hansen)
Organization: AT&T Bell Labs NJ USA
Lines: 46

< From: staff@cadlab.sublink.ORG (Alex Martelli)

<< In general, multiple inheritance is almost never needed.  I have never
<< seen a published example of a C++ program using multiple inheritance that
<< couldn't be coded just as easily using components instead.

< This is a major thesis of T. Cargill, and he's been propounding it at
< Usenix and UKUUG; indeed, he has rewritten all published examples of
< multiple inheritance in C++, with single inheritance or none at all, and
< they're better (see the proceedings of the above conferences).

< Also think of the practical concerns - maybe there are cases where MI
< would not be needed IF one could redesign each and every class hierarchy
< from scratch, but MI makes it easier to reuse specs and code, maybe from
< vendor-bought hierarchies, WITHOUT redesign...?

Let me try to summarize Tom Cargill's position on multiple inheritance (MI):

    o	He has been able to rewrite all published examples of MI using
	either single inheritance (SI), composition (using member variables),
	or both.

    o	He feels that the rewritten versions are cleaner and easier to
	maintain.

    o	One exception which he concedes is in the use of multiple vendor
	libraries, which might possibly be combined through MI.

    o	In either case, he feels that virtual bases are not necessary
	because those are ONLY needed when designing in MI and he feels that
	the alternative designs using SI and composition are better.

    o	Tom is also on the lookout for a use of MI which absolutely cries
	out for MI and can't be cleanly done any other way.

I feel that the concepts of "cleaner" and "easier to maintain" are very
subjective. I think that thinking in terms of MI may suggest a solution to a
problem more quickly, or may suggest alternate ways of thinking about the
problem, even if you don't wind up using MI in the end. In other words, it's
a tool in your toolbox that shouldn't be categorically denigrated.

I've yet to be convinced one way or the other by Tom's arguments.

					Tony Hansen
				att!pegasus!hansen, attmail!tony
				    hansen@pegasus.att.com