Xref: utzoo comp.lang.eiffel:1391 comp.object:2532
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!olivea!decwrl!asylum!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Summary: Sometimes you change the implementation class.
Keywords: polymorphism
Message-ID: <4482@osc.COM>
Date: 8 Feb 91 02:10:09 GMT
References: <488@eiffel.UUCP> <27A86309.281A@tct.uucp> <1991Feb1.135956.12425@tukki.jyu.fi> <27ADD06B.46A3@tct.uucp> <1991Feb5.130359.9735@bellcore.bellcore.com> <1991Feb6.045542.791@visix.com>
Reply-To: jgk@osc.COM (Joe Keane)
Followup-To: comp.lang.eiffel
Organization: Versant Object Technology, Menlo Park, CA
Lines: 36

One possibility is that RECTANGLE and POLYGON are separate concepts which have
nothing to do with each other.  Then there's not much to talk about.

Let's assume that the RECTANGLE class is entirely an optimization.  It's
simply a way of doing POLYGON faster in those cases where you can.  This is
quite likely in a graphics application.  You can do a lot of things more
efficiently if you know something is a rectangle rather than a general
polygon.  For example, the X protocol has special cases for rectangles.

Some routines will know about RECTANGLE and deal with its instances
differently.  Those routines which act on polygons would test if the polygon
is actually a RECTANGLE instance.  There may be some interface which applies
only to RECTANGLE instances.  For example, we may have methods which return
the corners of the rectangle, or the attributes may be directly accesible.

However, most methods do not know about RECTANGLE, only POLYGON.  Given this,
we should insist that the RECTANGLE optimization be transparent.  We should be
able to add a vertex to any polygon, regardless of its implementation class.
That's what polymorphism is all about.  Saying that it works for accessors but
not for modifiers is going only half way.

If we add a vertex to a RECTANGLE instance, then it will have to change its
implementation class to something else.  Perhaps we have a PENTAGON class or
maybe it's just converted back to a generic POLYGON.  Many OO languages don't
deal well with this, although CLOS does.

If a variable is declared as POLYGON, we can add a vertex to it.  It should
have no idea that the implementation class is being shifted from RECTANGLE to
PENTAGON under it.  On the other hand, if a variable is declared as RECTANGLE,
we can't add a vertex.  This is a type error and hopefully will be caught at
compile time.

Global type checking doesn't make sense.  Either an operation is correct or it
isn't.  How can the definition of a class depend on how you use it?  I won't
even talk about the practical problem of having your type checker hunt down
everyone who uses a given class.