Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object
Subject: Re: Examples of Multiple Inheritance?
Message-ID: <1056@tetrauk.UUCP>
Date: 12 Dec 90 15:03:19 GMT
References: <60700005@inmet> <980@culhua.prg.ox.ac.uk> <17562@neptune.inf.ethz.ch> <743@puck.mrcu>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 58

In article <743@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes:
>I think that this debate is missing the point.

It is indeed!

>Neither MI or SI make
>simple examples easier to code.  If you have fully analysed your
>problem and know what routines are to be called where then you can
>code in Pascal or C just as easily.

I sometimes wonder if half (most?) the people using OOPLs are simply replacing
top-down functional decomposition with top-down object decomposition.  The sort
of approach which says that "SI is better because it leads to a more structured
hierarchy" makes me think that this is what is happening.  There are lots of
ways to produce a structured solution to a _specific_ problem;  object
orientation is just one way to do it.  But that doesn't make your system more
resilient to change, which is the real point.

>The point about inheritance and
>polymorphism is that they contribute to code flexibility and reuse.
>When the requirements change (as they always do) then a well designed
>OO program is far superior because the existing abstract classes (what
>Meyer terms "deferred" classes) from which the actual classes inherit
>become the basis for new classes.  MI allows the designer to increase
>the number of abstract classes in the system and thereby increases the
>flexibility of the system.

The most important point about reuse is the ability to reuse something in a way
that was not anticipated when it was written.  Rigid hierarchies don't stand
much chance of letting you do that.

In a function oriented system, reuse is provided by function libraries.  These
work quite well, but we all know that they are limited in scope because of
problems of encapsulation and extension.  The acclaimed benefit of object
oriented methods is better reusability.  In a real _class based_ system, reuse
comes from class libraries, which are not only better encapsulated (if properly
written) but also reusable in two dimensions;  either as supplier classes (by
creating and using objects of the classes as they are), or by inheritance,
allowing controlled but essentially arbitrary extension.

The original question can be posed in the reverse:  If I wish to reuse
components from a class library by inheritance, under what circumstances is it
reasonable for me to be restricted to reusing only a single class at a time?

Would it be a reasonable restriction of C if a function I wrote were only
allowed to call one other sub-function?

I feel this concern about MI is all to do with implementation problems of
languages which have been (short-sightedly) designed without due consideration
for the ultimately essential support of multiple inheritance.

That is until someone comes up with a concept which is even better (and there
do seem to be some ideas bouncing around).
-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan