Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!fuug!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel
Subject: Re: Inheritance and Information Hiding
Message-ID: <1991Feb8.135849.26444@tukki.jyu.fi>
Date: 8 Feb 91 13:58:49 GMT
References: <1081@tetrauk.UUCP> <821@puck.mrcu> <10900@pasteur.Berkeley.EDU>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 28

In article <10900@pasteur.Berkeley.EDU> om@icsib29 (Stephen M. Omohundro) writes:
>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.
> ...

An obvious implication of the above principles would be that
modifications of classes and methods in a Sather environment
will often cause _massive_ recompilations, wouldn't it?
In particular, if some new class leaves any inherited feature F undefined,
then all clients of all appropriate superclasses must be rechecked.
(If the programming environment registers client relationships to
the utmost detail, those client classes that invoke F through
a "heterogeneous" variable - such as 'pd' above - can be pinpointed
directly.)

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)