Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!efi!tim
From: tim@efi.com (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Multiple Inheritance -- Is It A Luxury?
Message-ID: <1990Jul5.223032.14604@efi.com>
Date: 5 Jul 90 22:30:32 GMT
References: <15132@reed.UUCP> <268BA8DC.4CD4@intercon.com> <8937@goofy.Apple.COM> <268C032E.5137@intercon.com> <1990Jul2.181147.1672@efi.com> <8967@goofy.Apple.COM>
Organization: Electronics For Imaging, Inc.
Lines: 82

In article <1990Jul2.181147.1672@efi.com> tim@efi.com (Tim Maroney) writes:
>> The people doing the MPW compilers seem to think that multiple
>> inheritance is not important.  It's not possible at all in Object
>> Pascal, and apparently is impossible to use in real (handle-based)
>> applications in C++.  I think this is a cavalier attitude.

In article <8967@goofy.Apple.COM> casseres@apple.com (David Casseres) writes:
>One clarification and two comments.  The clarification:  C++ on the Mac 
>does not allow multiple inheritance for subclasses of THandleObject; but 
>it can be used with all other classes.  It doesn't matter whether the 
>application uses THandleObject subclasses in addition.  Note that it is 
>not necessary for everything to be handle-based.

I haven't used the C++ MacApp, but isn't it handle-based?

>First comment:  The restriction on THandleObject subclasses and multiple 
>inheritance is due to serious implementation difficulties that have been 
>explained in this group, not to a cavalier attitude.

Not really.  I have yet to run into a programming model using pointers
into nonrelocatable blocks that couldn't be rephrased in terms of
offsets into relocatable blocks.  It may require some work on the part
of the compiler developer -- since they didn't do it right the first
time -- but it's hardly a serious implementation difficulty.  It's a
well-known programming practice.

>Second comment:  There is some justification for a cavalier attitude about 
>multiple inheritance, just as there is justification for wanting it very 
>badly in some cases.  Brian Bechtel sums it up very well in saying 
>"Multiple inheritance is the GOTO of the 1990's."  It is tremendously 
>powerful, lets you do any damn thing you like, elegantly solves certain 
>problems, leads to utterly obscure code, and invites massive abuse that 
>can cause enormous damage to the integrity of code.

Hmm.  Power can always be abused.  The more power you give a developer,
the more power she has to write either elegant or inelegant code.  There
are very few cases in which the power of a GOTO leads to cleaner code
(certain software implementations of finite-state machines are all that
springs to mind), but I don't think that multiple inheritance is one of
these inherently risky powers.

Writing a better programming language is a matter of psychology.  How
cleanly do the programming language's concepts and tools map into the
way that humans inherently view objects and tasks?  A loop construct is
closer to the ordinary human way of seeing tasks than is a GOTO.  If
we're telling soemone how to do something, we might say "do this ten
times" or "keep doing it until the film is dry" or something of that
kind; we are much less likely to say "go back to step 5".

Object programming is another step towards more human conceptualization
of tasks.  The whole notion of class inheritance is based on the human
division of phenomena into categories and subcategories.  Because of
this, object programming can lead to solutions that seem more "natural"
and "clean".  But humans also naturally perceive categories in terms of
multiple inheritance; that is, many phenomena are routinely considered
members of classes which are not descendants of each other.  Because of
this, multiple inheritance is a step closer to human concepts, unlike
GOTO which is an artificial contrivance unrelated to normal human modes
of perception.  So I don't think the a comparison between multiple
inheritance and GOTO is accurate.  If anything, they are opposites.

>In my own limited experience with C++, I have found that a redesign of the 
>hierarchy always leads to cleaner, more elegant code than multiple 
>inheritance.  But then, I'm not using a hierarchy containing a lot of 
>libraries produced by other people.  If I were, I might want to use a lot 
>of multiple inheritance; but on the other hand, I think that in that 
>situation what I would *really* want is source code for all the libraries 
>so I could re-implement them to suit my purposes!  That, not any lack of 
>features, is the problem with any OOPS that gives you only compiled 
>libraries instead of source code.

I don't agree.  You shouldn't have to modify source code to use an
object library.  It leads to an immediate drop in confidence in the
code's reliability, which is to say, when you get a bug, you never know
whether it's because of code you've added or because of the changed
object library.  It's possible that you've violated subtle assumptions
of the library, so you have to spend a great deal of time just plowing
through source code that you should never need to see.

If I have one big complaint with MacApp so far, it is precisely that
you have to read the source code all the time.  If you have to change
the code to do things, then this problem gets even worse.