Xref: utzoo comp.lang.eiffel:1424 comp.object:2582
Path: utzoo!attcan!uunet!europa.asd.contel.com!sura.net!haven!boingo.med.jhu.edu!aplcen!samsung!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!mucs!cs.man.ac.uk!mario
From: mario@cs.man.ac.uk (Mario Wolczko)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <2082@m1.cs.man.ac.uk>
Date: 31 Jan 91 19:16:53 GMT
References: <1991Jan23.224203.3206@runx.oz.au> <1991Jan24.214652.18515@Think.COM> <10612@pasteur.Berkeley.EDU> <485@eiffel.UUCP> <488@eiffel.UUCP>
Sender: news@cs.man.ac.uk
Reply-To: mario@cs.man.ac.uk (Mario Wolczko)
Followup-To: comp.lang.eiffel
Organization: Department of Computer Science, University of Manchester
Lines: 66

In article <488@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes:
> 
> 	Anyone who wants to argue that the Eiffel policy is not the
> appropriate one is going to have to leave pious generalities
> and offer serious technical arguments.
and then offers some design alternatives...

...but the options he then lists are not exhaustive.  Eiffel allows
the programmer to control the visibility of any feature to clients via
the export clause.  The problem is that *all* features are visible to
children.  If, in the implementation of a class (especially a deferred
class), the programmer needs a feature (be it a routine or attribute)
for purely private use, and which can be provided in a number of
different forms, then it should be possible for the programmer to say,
``Don't assume that this will be present in this form in all versions
of this class'', ie that children should not be able to use this
feature.  That's what the protected mode of C++ is for.  If the
feature is protected, then the implementor of the class is free to
change or remove it, provided that the advertised interfaces (to
clients and children) work as advertised!

An inability to do this violates what I call "the Principle of
Decomposition": at any time the programmer should be free to decompose
one thing into more than one thing, without affecting the advertised
interface or behaviour.  If you mention this in isolation, most people
nod in agreement.  But no mainstream OO language satisfies it!  If we
substitute "feature" for "thing", then Eiffel fails because of the
described behaviour: the extra features appear in the subclass
interface.  If we substitute "class" for "thing" (ie decompose one
class into two classes, related by inheritance), then *no* mainstream
OO language can satisfy the principle, because one cannot localise the
interaction between parent and child (self/this/current is always
bound in the class of the receiver, which may be a descendant of the
child).

None of this is new to OOP: it's a problem in any ADT theory/language:
Can you implement any ADT and not have the implementation show
through?  The philosophical point is whether you feel that the
parent/child boundary consititutes an interface at which hiding should
be possible.  I do; I know Dave Ungar doesn't (he told me); I'd be
interested to hear what Bertrand Meyer thinks.

I think the point is well-argued in Snyder's paper [1], and I was
surprised when I came across Eiffel that it did not adopt this policy
(especially in view of its "software engineering" stance).  I feel
sure that Bertrand Meyer was aware of this paper when designing
Eiffel, so perhaps he could explain his decision to do otherwise?

> All too often we forget that design methodology and programming
> languages are meant to help people produce good software, not
> to restrict their creative freedom.
Quite.  I want the freedom to create classes with *exactly* the
interfaces (client & child) I want.

[1] Alan Snyder, Inheritance and the Development of Encapsulated
Software Components, Research Directions in Object-Oriented
Programming, MIT Press, 1987, pp147-64 (an earlier version appears in
OOPSLA 86).

Mario Wolczko

   ______      Dept. of Computer Science   Internet:      mario@cs.man.ac.uk
 /~      ~\    The University              uucp:      mcsun!ukc!man.cs!mario
(    __    )   Manchester M13 9PL          JANET:         mario@uk.ac.man.cs
 `-':  :`-'    U.K.                        Tel: +44-61-275 6146  (FAX: 6280)
____;  ;_____________the mushroom project___________________________________