Xref: utzoo comp.lang.eiffel:1375 comp.object:2512 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!bu.edu!m2c!umvlsi!dime!blerner From: blerner@empire.cs.umass.edu (Barbara Lerner) Newsgroups: comp.lang.eiffel,comp.object Subject: Re: Inheritance and Information Hiding Message-ID: Date: 6 Feb 91 15:05: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> Sender: news@dime.cs.umass.edu Followup-To: comp.lang.eiffel Organization: /u/zoo/blerner/.organization Lines: 95 In-reply-to: adam@visix.com's message of 6 Feb 91 04:55:42 GMT > From: adam@visix.com (Adam Kao) > [..] > 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? [..] The distinction between adding a vertex to a polygon and adding a vertex to a rectangle is the following. When a vertex is added to a polygon, no new object is created. The same polygon object exists but has one more vertex. If we take the point of view that we can add a vertex to a rectangle with the result begin a pentagon, we now have two choices: 1. Create a new Pentagon object that is a "copy" of the rectangle with the added vertex. 2. Add the vertex to the rectangle object, and change its class from rectangle to pentagon. The first solution is fundamentally different from adding a vertex to the object. For example, if we have an object O with a field p of type polygon. O.p := make_polygon(..) O.p.add_vertex(..); In this case, O.p will be a polygon with one more vertex than it was originally created with. Suppose instead, we do: O.p := make_rectangle(..) O.p.add_vertex(..); Now, O.p is still a rectangle since we haven't changed O.p, but created a new object instead. Of course, we could say: O.p := O.p.add_vertex(..); This places the burden on the user of add_vertex to make sure that all references to the rectangle are appropriately updated. Keep in mind that there may be more than one object referenceing the rectangle. The second solution is not type safe in the following situation. Suppose we have an object O with two fields: p of type polygon, and r of type rectangle. Now suppose we execute the following code with add_vertex changing the class of the rectangle to pentagon. O.r := make_rectangle(..); O.p := O.r; O.p.add_vertex(..); If we change the class of the rectangle to pentagon, then O.r now refers to a pentagon while the class of O.r is declared to be rectangle. *Accurately* detecting this situation at compile-time is probably impossible. Detecting it at runtime would require every object to maintain backpointers to all objects that reference it, so that all class changes could be type-checked. Barbara Lerner -- Barbara Staudt Lerner Deparment of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 blerner@cs.umass.edu