Xref: utzoo comp.lang.eiffel:1344 comp.object:2466
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <488@eiffel.UUCP>
Date: 31 Jan 91 03:12:32 GMT
References: <1991Jan23.224203.3206@runx.oz.au> <1991Jan24.214652.18515@Think.COM> <10612@pasteur.Berkeley.EDU> <485@eiffel.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 67


	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.

	Will anyone take up the simplest example (discussed in my
posting <485@eiffel.UUCP>): a class POLYGON exists and has
a procedure ``add_vertex'', which it exports.
You want to add a class RECTANGLE. What do you do?

1. Decide not to use inheritance. No comment.

2. Redo the existing inheritance hierarchy. Of course,
even assuming you are permitted to do it, this will only
save you temporarily: someone else, or you a while later,
will want to perform new changes based on criteria other
than fixed versus variable number of vertices:
for example regular versus irregular, etc. You'll soon
have a total mess if you are trying to keep up with various
conflicting classifications.

3. Accept that RECTANGLE inherits from POLYGON and does not export
``add_vertex''. (This procedure violates the invariant of class
RECTANGLE anyway, so the consistency rules forbid it to be exported,
but of course non-exported routines do not have to maintain the
invariant.) To avoid burdening the compiler writer,
call this ``implementation inheritance'' and disallow
polymorphic assignments of the form p := r where p is of type
POLYGON and r of type RECTANGLE.

4. Accept that RECTANGLE inherits from POLYGON and does not export 
``add_vertex''. Permit polymorphic assignments of the above form;
but have the type checker reject as invalid any system which would
contain both such an assignment and a call p.add_vertex (...), since
it may lead to a run-time inconsistency. Do not introduce
any distinction between ``implementation inheritance'' and any other
kind.

Based on not inconsiderable experience with the design of O-O systems
and class hierarchies, I believe that solution 4 is the only reasonable
one. I would be interested to see any technical counter-argument,
and alternative solutions to the problem mentioned above.

Of course solution 4 causes more work for implementers, since
type checking must now be done on an entire system rather than a
single class. But that's what computers are for: tedious, exhaustive
work, especially when (as here) the consequences of not doing that
work are potentially rather damaging. In earlier articles I have
described a strategy for doing the work in an incremental fashion
so that its performance overhead is acceptable.  

As an aside (meant to be thought- rather than flame-provoking)
I have come to realize, although not early enough, that
information hiding is a greatly overrated goal. What counts
is abstraction.  Information hiding is often a convenient
syntactical way to help achieve abstraction, but is a means
rather than an end, and is not desirable in 100% of cases.
It must always be tempered with other criteria.

Just because David Parnas and many others after him
(including the undersigned) have emphasized the potential benefits
of information hiding in well-defined cases does not make
incantation a substitute for thinking.

(Another of these incantations is ``implementation inheritance''.
This does not mean anything. In class POLYGON, why would
``add_vertex'' be implementation and ``access_vertex''
specification?)

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.
-- 
-- Bertrand Meyer
bertrand@eiffel.com