Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!gatech!ncar!tank!nucsrl!gore
From: gore@eecs.nwu.edu (Jacob Gore)
Newsgroups: comp.lang.eiffel
Subject: Re: Re: multiple inheritance example
Message-ID: <13130001@eecs.nwu.edu>
Date: 21 Jan 89 22:55:48 GMT
References: <5037@cognos.UUCP>
Organization: Northwestern U, Evanston IL, USA
Lines: 43

/ comp.lang.eiffel / donw@cognos.uucp (Don Walker) / Jan 16, 1989 /
>One of the major differences between inheriting a class and being a client of
>a class is that being a client restricts you to using the public interface.
>... the current inheritance mechanism is overkill [if] you only required
>access to the public features.
>It is my opinion that it would be useful to be able to distinguish between
>unrestricted inheritance (the current implementation) and limited inheritance
>which would allow only the public interface to be "inherited".

The issue of whether an heir should get access to the internal workings of
its ancestor seems to split people into two camps.  Suppose class B
inherits from class A.  Should the implementor of B be able to couple B's
implementation so tightly to A's implementation?  The problem, of course,
is that if the implementor of A decides to change the implementation, B is
likely to break (unless it keeps using the older version of A -- but having
to maintain multiple implementations of the same class is not a pleasant
thought).

In one camp you have people who say, "No, this coupling is too tight".
(For example, Barbara Liskov made this point in her keynote address at
OOPSLA'87.)  In the other, you have people who say that the implementor of
B should be allowed to choose whether or not to risk the tight coupling.

It is in the interest of the provider of a class (implementor of A) to hide
the implementation, but it is in the interest of the user of that class
(implementor of B) to be able to take advantage of it.  Conflict of
interests!

I think the idea that the implementor of B is the one taking a risk is too
simplistic: if the software system is scheduled to go into QA in a week,
and A's implementation is changed, thus breaking B, it will be the
implementor of A who will be pressured (or forced) to change the
implementation back so that B can keep functioning.  This is why I tend to
lean to the "this is too tight" side.

Don Walker suggests that both types of inheritance should be available.  I
agree with the general idea, but it still begs the question:

	Who decides which type to use: the author of the inherited
	class, or the author of the inheriting class?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,gargoyle,att}!nucsrl!gore