Xref: utzoo comp.lang.eiffel:1389 comp.object:2530
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!think.com!linus!agate!pasteur!om
From: om@icsib29 (Stephen M. Omohundro)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <10900@pasteur.Berkeley.EDU>
Date: 8 Feb 91 00:20:28 GMT
References: <10612@pasteur.Berkeley.EDU> <485@eiffel.UUCP> <488@eiffel.UUCP> <1991Feb1.015749.10111@Neon.Stanford.EDU> <1081@tetrauk.UUCP> <821@puck.mrcu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: om@icsib29 (Stephen M. Omohundro)
Followup-To: comp.lang.eiffel
Organization: International Computer Science Institute, Berkeley, Ca.
Lines: 15
In-reply-to: paj@mrcu (Paul Johnson)
Originator: om@icsib29

Just a quick note on the Sather solution to the POLYGON vs. RECTANGLE problem.
In Sather the distinction is made between a variable declared as "pa:POLYGON"
which is guaranteed to hold an actual polygon object and "pd:$POLYGON" which can
hold a polygon or any of its descendents. In Sather there is no neccessity for
descendent classes to define all the features of its ancestors (and there is an
"UNDEFINE" mechanism to eliminate features). If the call "pd.add_vertex"
appears, then the compiler checks all descendents of POLYGON and complains if
"add_vertex" is missing from any of them or has an incompatible interface. On
the other hand, the call "pa.add_vertex" is perfectly legal regardless of the
descendent's class definitions. If "add_vertex" is only meant to apply to actual
POLYGON objects, then such declarations guarantee that they will not be applied
to objects of descendent classes. In this way the use of inheritance to reuse
features of a parent class in a child class is somewhat separated from its use
in constraining dynamic dispatch.
--