Path: utzoo!attcan!uunet!efi!tim
From: tim@efi.com (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Multiple Inheritance -- Is It A Luxury?
Message-ID: <1990Jul2.181147.1672@efi.com>
Date: 2 Jul 90 18:11:47 GMT
References: <15132@reed.UUCP> <268BA8DC.4CD4@intercon.com> <8937@goofy.Apple.COM> <268C032E.5137@intercon.com>
Organization: Electronics For Imaging, Inc.
Lines: 53

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.  I've only
been using Object Pascal for a couple of months now, and my only
earlier OOP experience was with a flavored dialect of Franz Lisp many
years ago; but I have already encountered a number of cases where the
lack of multiple inheritance imposes inelegant solutions.  The
"seaplane" analogy seems to be a frivolous way of dismissing this
important technique.

First case:  Extending a class library.  Suppose that programmer A adds
good, general Windows menu support to MacApp.  There are basically two
ways of doing this.  The first is to create a class library add-on
providing a number of methods which are supposed to be called at
various points in other deveopers' applications.  The other is to
create a subclass of TApplication that calls all these methods at the
appropriate places.  In the first solution, the developers using this
code have a considerably greater burden in terms of
documentation-reading and error avoidance and code modification; in the
second solution, developers only need to make their applications
sub-classes of the sub-classed TApplication, a one-word code change.
Obviously the second solution is cleaner.

But now suppose someone else takes the same approach to add, say,
walk-through keyboard-oriented menus.  OOPs!  You can't make your
application a subclass of *both* TWinMenuApplication and
TWalkMenuApplication.  There's no multiple inheritance.  One or the
other has to revert to the bad old "insert tab A into routine B"
solution.

Second case:  Managing a list of largely dissimilar objects that have
some common behavior.  For instance, suppose that you are keeping a
list of objects, some of which are TViews, some of which are TCommands,
some of which are on your own inheritance tree from TObject.  They
can't be given common methods, because you can't make something a
descendant of both TView and your common-methods class.  Multiple
inheritance would make for a very clean solution.  Instead, you have to
put in type-coercion case statements using class ids, or have each list
entry associated with a separate object sub-classed on a
per-list-element-type basis which implements the common methods while
knowing what type of object the message is being passed on to.  Both of
these are very clunky solutions to a problem which is cleanly solved by
multiple inheritance.

If I were in the languages groups at either Apple or Symantec, I
would consider it a high priority to bring multiple inheritance into
Object Pascal and to make it usable with C++ or Object C.  Elegant
solutions are not a luxury.  Clean code is more maintainable and less
buggy.  If someone has a personal dislike of multiple inheritance and
doesn't want to use it, fine.  Adding it to the language imposes no
such burden on these people.  But omitting it does impose a burden
on those of us in the other camp.