Xref: utzoo comp.lang.eiffel:1363 comp.object:2488
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.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <1081@tetrauk.UUCP>
Date: 1 Feb 91 11:32:28 GMT
References: <10612@pasteur.Berkeley.EDU> <485@eiffel.UUCP> <488@eiffel.UUCP> <1991Feb1.015749.10111@Neon.Stanford.EDU>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 61

In article <488@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>
>	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?

This thread seems to me to be exposing one of the fundamental problems of
inheritance, which is the distinction between mutable and imutable objects.

Given that inheritance implies both specialisation and extension, then if
objects are considered fixed once created there is no problem: a rectangle is
clearly a descendant of polygon, since it is a specialised version.  Everywhere
that a fixed polygon may be used, then a fixed rectangle may be used, so a
rectangle is type conformant with a polygon.

However, when we allow objects to be modified we are seriously challenging the
whole concept of taxonomy.  In fact in the shapes example, the type conformance
appears to be inverted.  In terms of modifying vertices, the polygon is type
conformant with a rectangle.

Both the CLOS solution of dynamically changing the object's class, and Bertrand
Meyer's solution of extended compiler type checking, seem to be ultimately
trying to address this problem.  Both have their advantages and drawbacks.  One
problem I see with allowing the class to change is that you might not want this
to happen inadvertently.  Bertrand's solution covers a more general aspect of
what might be called "partial inheritance", but I can see the sort of errors
the compiler might generate proving very frustrating for programmers, and lead
to all sorts of ugly cross-assignments being used in order to keep the compiler
quiet.  This sort of code could also well appear pointless on first reading,
and confuse novice programmers (this is speculation, since I have not yet had
to live with such a compiler).

Has anyone tried to address this problem by considering that a class
essentially has two interfaces?  One - the "read" interface - provides
information about the object in its current (abstract) state.  The other - the
"write" interface - offers facilities to change the object.  It seems that if
the language supported the ability to define not only the class TYPE of a
variable, but also the class USAGE (read or write), then the restrictions would
be clearer, both to the compiler and to the programmer.  It's a little like the
C++ "const" qualifier, but taking the semantic implications a lot further.

Eiffel would be well suited to handle this notion, since it already
distinguishes between functions/attributes and procedures.  The concept of
declaring an Eiffel reference as "read-only" would simply prevent it being used
to call procedures of the class - only access to attributes and functions would
be allowed (good Eiffel design avoids the use of functions which have side
effects on the the object's abstract state).  This is not a substitute for
Bertrand's more general global type-checking, but would make code clearer in
representing the current use of the object, and catch errors earlier.

I believe it could also simplify the global typing problem, since read-only
variables would already be limited as to the range of features available to
them, but I haven't had time to consider this in any depth.  Have any of the
theorists out there done any work along these lines?

-- 
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