Xref: utzoo comp.lang.eiffel:1398 comp.object:2543
Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!visix!news
From: adam@visix.com (Adam Kao)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <1991Feb6.045542.791@visix.com>
Date: 6 Feb 91 04:55:42 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>
Sender: news@visix.com
Reply-To: adam@visix.com (Adam Kao)
Organization: Visix Software Inc., Reston, VA
Lines: 60


I have some random thoughts on this topic; Yves J Caseau's posting
brought my ideas together, to the point where I would like to pursue
them further in public.

I have always felt uncomfortable with the emphasis on "Class" in
languages like Smalltalk, C++ etc.  To me, the notion of an Object
seems much more basic and fundamental than a Class.  Everybody knows
that real-world classes are not well-behaved; they are not disjoint,
they are not proper subsets, class membership changes over time.

I see object oriented techniques such as tree heirarchies, multiple
inheritance, etc., as attempts to make Classes well-behaved.  But in
doing so, I feel that we increasingly distance our notion of Class
from the common-sense notion of class, which necessarily makes
object-oriented programming harder to understand.

In the real world, objects do not, strictly speaking, belong to a
class.  A classification system is imposed on real objects by our
world view; class membership is an answer to a question we phrase.
Different question, different answer.

To my mind, classes can be viewed as schema that define invariants
among their members.  Every object is then potentially a member of
as many classes as we care to define.  

Since any trait of an object can be considered a defining invariant
for some class, it then becomes inevitable that any trait change will
remove the object from some classes and add it to others.

An abstract RECTANGLE satisfies all the invariants of a POLYGON, so it
is natural to have RECTANGLE inherit from POLYGON.  But a RECTANGLE
has additional invariants, so operations that are closed over POLYGONs
are not closed over RECTANGLEs.

We know how to add vertices to POLYGONs.  I think it ridiculous to say
we do not know how to add vertices to RECTANGLEs.  The problem is,
adding a vertex to a RECTANGLE gives us something that is not a
RECTANGLE.  

I do not see this as a problem.  Why do we expect that all operations
on an Object must be closed over its Class?

Most languages have type-casting and type-promotion.  In C, we can add
a double to an int, and the result will be a double.  Is this kind of
arithmetic forbidden in object-oriented programming?

To me, the statements "p := r" and "p.add_vertex(...)" are perfectly
compatible.  The "p := r" should imply a cast; if we want to make the
assignment, it means we want to treat rectangles as polygons.  Surely
the explicit conversion "p := r.make_polygon()" followed by
"p.add_vertex(...)" is acceptable; why not accept even
"r.add_vertex(...)" as a shorthand?

I believe that this discussion is evidence that our notion of a Class
is too weak to support all the uses we expect.  Of course, I was
predisposed to this conclusion.  But, I most certainly hope to hear
more discussion on any side of this issue.

Adam