Xref: utzoo comp.lang.eiffel:1364 comp.object:2489
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.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: <493@eiffel.UUCP>
Date: 2 Feb 91 00:15:25 GMT
References: <10612@pasteur.Berkeley.EDU> <485@eiffel.UUCP> <488@eiffel.UUCP> <1991Feb1.015749.10111@Neon.Stanford.EDU>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 77

From <1991Feb1.015749.10111@Neon.Stanford.EDU>
by craig@Neon.Stanford.EDU (Craig D. Chambers):

> >
> >a class POLYGON exists and has
> >a procedure ``add_vertex'', which it exports.
> >You want to add a class RECTANGLE. What do you do?
> >
> >3. Accept that RECTANGLE inherits from POLYGON and does not export
> >``add_vertex''. [...] 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.
> 
> Option 3 seems like the only reasonable solution to me.  And I'm not
> ...
> The real problem with option 4 is that a large existing
> legal program can be invalidated by a single added line.
> 
> Say you have a large application manipulating various shapes,
> including rectangles and polygons as above.  Now say someone adds a
> single line to the program, say an assignment "p := r".  If in the
> rest of the application there are no such assignments, but many calls
> on p.add_vertex, then all these calls are suddenly invalidated by the
> new assignment.  This seems incredibly wrong.  The legality of earlier
> add_vertex calls shouldn't depend on whether some future programmer
> makes an assignment "p := r"; instead, the new assignment should be
> marked illegal.

There is a point here. But you may look at it in the following way.
What is illegal is the presence in the same system of both
of the instructions

[A]		p := r
[B]		p.add_vertex

The error may be in one or in the other. In the situation described
by Mr. Chambers, assume we have an incremental compiler,
and a lot of existing code uses [B]. If someone tries
to add [A] to the system, then this will be flagged by the
incremental compiler, which will point at the most obvious
source of the problem: the new occurrence of [A], not the
existing occurrences of [B]. This invalidates the addition,
not the existing code, which is what Mr. Chambers wants.

In this case we get the effect of solution 3,
but with much less burden on the programmer because many
cases which solution 3 would flag as invalid will be accepted
since they don't raise any problem.

My impression is that uniformly rejecting the cases 
which satisfy 4 but not 3 would significantly restrict the
programmer's power of expression, and that they are
important and useful in practice.









-- 
-- Bertrand Meyer
bertrand@eiffel.com