Xref: utzoo comp.lang.eiffel:1358 comp.object:2482
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <1991Feb1.135956.12425@tukki.jyu.fi>
Date: 1 Feb 91 13:59:56 GMT
References: <485@eiffel.UUCP> <488@eiffel.UUCP> <27A86309.281A@tct.uucp>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 61

In article <27A86309.281A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to bertrand@eiffel.UUCP (Bertrand Meyer):
>>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.
>>2. [...]
>> ...

>In C++, the add_vertex() member function would almost certainly be
>virtual; that is, it would act correctly in cases where a |POLYGON*|
>actually points to an object of type |RECTANGLE|.  (If it were not
>virtual already, it could be made so by the insertion of the word
>"virtual" at one place in the code.)

Sorry, that was not the difficulty.  On the contrary, in Eiffel,
Smalltalk, and many other OOPL's _all_ procedures are virtual
in the Simula/C++ sense.

>Given this language feature, add_vertex becomes a non-problem.  The
>implementor of RECTANGLE simply provides an appropriate definition of
>the RECTANGLE::add_vertex(): a do-nothing function body that returns a
>failure indication (if appropriate).

This is only possible if either:
1. 'add_vertex' was originally declared with a return value or parameter
   that indicates success or failure.  One would not like to add such
   parameters to the majority of procedures, because they tend to
   complicate the code too much.
2. The language has an exception mechanism;  incidentally, Eiffel has
   it but C++ hasn't - well, there is a suggestion in the Ellis &
   Stroustrup book.

>Analyzing this use of C++ results in a fifth item for Bertrand's list:
>
>5.  Accept that RECTANGLE inherits from POLYGON and exports add_vertex,
>    and require the programmer to provide an implementation of add_vertex
>    appropriate for a RECTANGLE.
>
>In the real world, how is this solution deficient?

The defect of this solution is that _all_ inapproriate invocations
of 'add_vertex' are detected only at run time.  Some other solutions
make it possible to classify the invocations into three classes
at compile time:
1. Those that are certainly correct.
2. Those that are certainly wrong and cause an error message.
3. Those that may be right or wrong and need a run-time check.

The bad news is that one must limit flexibility and polymorphism
if one wants to avoid run-time checks completely.
(I'll return to this in another posting.)

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)