Xref: utzoo comp.lang.eiffel:1371 comp.object:2500
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip
From: chip@tct.uucp (Chip Salzenberg)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <27ADD06B.46A3@tct.uucp>
Date: 4 Feb 91 21:21:46 GMT
References: <488@eiffel.UUCP> <27A86309.281A@tct.uucp> <1991Feb1.135956.12425@tukki.jyu.fi>
Organization: Teltronics/TCT, Sarasota, FL
Lines: 24

According to sakkinen@jytko.jyu.fi (Markku Sakkinen):
>In article <27A86309.281A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>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.
>2. The language has an exception mechanism ...

I discern that my suggestion was inadequate.  I withdraw it.

I now agree, however, with those who suggest that RECTANGLE is not an
appropriate derivation of POLYGON.

There is an assumption built into a POLYGON interface that includes an
add_vertex() function: that a POLYGON may be modified in its number of
vertices.  The derivation of RECTANGLE from POLYGON violates that
assumption.  Separate inheritance subtrees of POLYGON, such as
FIXED_POLYGON and VARIABLE_POLYGON, now seem to me the best way to go.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "Most of my code is written by myself.  That is why so little gets done."
                 -- Herman "HLLs will never fly" Rubin