Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!tukki.jyu.fi!sakkinen From: sakkinen@tukki.jyu.fi (Markku Sakkinen) Newsgroups: comp.lang.eiffel Subject: Re: Inheritance and Information Hiding Message-ID: <1991Feb7.091114.5021@tukki.jyu.fi> Date: 7 Feb 91 09:11:14 GMT References: <1991Feb5.130359.9735@bellcore.bellcore.com> <1991Feb6.045542.791@visix.com> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) Organization: University of Jyvaskyla, Finland Lines: 72 In article blerner@empire.cs.umass.edu (Barbara Lerner) writes: > >> From: adam@visix.com (Adam Kao) >> >[..] >> 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? >[..] > ... [long discussion deleted] >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. The analysis was thorough and correct, but it assumed that variables are always references. That is indeed the case in almost all well-known OOPL's, but probably the previous poster meant _value_ and not reference assignment, as in typical non-OO procedural languages (Pascal, Ada, C, ...). Then the sharing problem inherent in reference semantics simply does not arise. Many readers of this newsgroup know that I am certainly not a C++ enthusiast, but one advantage of C++ is that it allows the programmer to declare both object-valued and reference-valued variables, depending on which is more suitable (e.g. semantically) for each situation. One drawback of C++ is that the dynamic class of an object-valued variable is always the same as its static class. Therefore, assigning (copying, converting) a subclass object to a superclass variable entails irrecoverable "type loss" (and usually other information loss too). Douglas Lea has suggested enhancements to C++ that would solve this problem to some extent; these suggestions could be implemented at least by what I would call "value semantics with reference pragmatics". In any case, in typical OOPL's (and this goes as well for C++ as for Smalltalk and Eiffel) a Rectangle class should not inherit any kind of _concrete_ Polygon class: the baggage would include not only some operations that are hardly appropriate for rectangles, but also unnecessary instance variables. One could in fact build workable software easier by making Polygon inherit Rectangle - conflicts between interface inheritance and implementation inheritance have often been described in the literature. The clean way would be to inherit from a suitably general abstract class. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)