Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!rit!prague!mjl
From: mjl@cs.rit.edu (Michael J Lutz)
Newsgroups: comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <2140@cs.rit.edu>
Date: 9 Feb 91 16:26:52 GMT
References: <1991Feb8.171341.19413@cs.tcd.ie>
Sender: news@cs.rit.edu
Reply-To: mjl@cs.rit.edu (Michael J Lutz)
Organization: Rochester Institute of Technology
Lines: 31

In article <1991Feb8.171341.19413@cs.tcd.ie>, cjmchale@cs.tcd.ie (Ciaran
McHale) writes:

|>Bascially we're torn between two seemingly conflicting issues:
|>
|>	1. We can't have rectangle as a subtype of polygon
|>	   since add_vertex doesn't make sense when applied
|>	   to a polygon.
|>	2. We do not want to duplicate code which is common
|>	   between rectangle and polygon.
|>
|>One way to solve this dilemma is for the language to have two
|>hierarchies rather than just one. There would be a TYPE
|>hierarchy and an IMPLEMENTATION (CODE) hierarchy.

Note that this is the solution employed in POOL (Parallel
Object Oriented Language), where the CLASS hierarchy is used to
define implementation reuse, and the TYPE hierarchy is used to refine
behavior.  If a particular CLASS exhibits the behavior required
of a TYPE, then objects in that class can be associated with
variables of the TYPE.

Check out the paper by America and van der Poel in the
1990 OOPSLA/ECOOP proceedings.
                        

---------
Mike Lutz
Rochester Institute of Technology
Rochester, NY 14623-0887
mjl@cs.rit.edu