Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object
Subject: Re: Examples of Multiple Inheritance?
Message-ID: <1990Dec5.184743.3963@odi.com>
Date: 5 Dec 90 18:47:43 GMT
References: <60700005@inmet> <2277.275bdf0b@iccgcc.decnet.ab.com>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 43
In-Reply-To: klimas@iccgcc.decnet.ab.com's message of 4 Dec 90 22:38:19 GMT

In article <2277.275bdf0b@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes:


	   1)I have thrown out the same challenge to the Smalltalk
	   community (yes ST-80 once had it and ST /V286 does support MI in the 
	   hierarchy via a simple change to Behavior, and there have been 3rd 
	   party add on browsers for V/286) for quite a while now, and I have 
	   not gotten any substantive examples other than simple mixins to date.

Since most Smalltalk users do not have access to a language with
multiple inheritance, it is hardly surprising that they are not a good
source of examples of multiple inheritance.

	   2)This is not a new topic. Per Borning and Engals 1982 "M. I. in ST-80"
	   Proc. of the Ntnl. conf. on AI, "The attempts at MI have not achieved
	   the elegance and simplicity of single inheritance."

That's quite true.  But that wasn't the question.  The question was
whether multiple inheritance was genuinely useful.  Fixed point is a
lot more elegant and simple than floating point, but many people find
floating point useful for certain applications.

	   3)A lot of people claim that MI is a strength of C++, however a number
	   of companies that are developing in C++ also have internal policies that
	   prohibit the use of MI because of the potential for unmanageable
	   complexity explosions in solutions that are of any size.  With MI in
	   C++, the user must now know about how every class and method is used
	   so that if he inserts a class in the hierarchy he won't break it.  This
	   goes against the idea of "comprehension avoidance", i.e. for effective
	   programming, limit the amount of stuff a programmer needs to know 
	   about a system to interact with it. 

Instead, when these companies try to model things that are best
described by multiple inheritance, they'll be forced to use something
kludgy and awkward instead, which will end up confusing their
programmers in the long run and making the software harder to
maintain.  You cannot eliminate complexity by simply deeming that it
shall not be there.  I certainly don't recommend using multiple
inheritance where single inheritance will do just fine.  I can even
believe that it's sometimes better to avoid multiple inheritance if
single inheritance plus a small kludge can do almost as well.  But
sometimes multiple inheritance is the natural way to model something,
and it should be used in those cases.


Brought to you by Super Global Mega Corp .com