Xref: utzoo comp.object:2550 comp.lang.eiffel:1403 Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!crackers!m2c!umvlsi!dime!blerner From: blerner@empire.cs.umass.edu (Barbara Lerner) Newsgroups: comp.object,comp.lang.eiffel Subject: Re: Inheritance and Information Hiding Message-ID: Date: 8 Feb 91 15:25:03 GMT References: <1991Feb6.045542.791@visix.com> <1991Feb6.214110.28256@Neon.Stanford.EDU> <1991Feb7.205232.23548@Neon.Stanford.EDU> Sender: news@dime.cs.umass.edu Followup-To: comp.object,comp.lang.eiffel Organization: /u/zoo/blerner/.organization Lines: 43 In-reply-to: craig@Neon.Stanford.EDU's message of 7 Feb 91 20:52:32 GMT In article <1991Feb7.205232.23548@Neon.Stanford.EDU> craig@Neon.Stanford.EDU (Craig D. Chambers) writes: > If you take the view that rectangle is a specialized *implementation* > of polygons, but the *type* of rectangle is still polygon, then this > class-changing operation is perfectly type-safe (as I mentioned in an > earlier posting). The add_vertex operation on rectangles modifies the > rectangle *in place* to be a pentagon-represented polygon; the > interface to the rectangle remains unchanged. This facility requires > that some classes be marked as not defining new types but instead new > implementations of existing types. This is an interesting solution. However, to clarify a point, it seems to me that this solution implies that clients of polygon do not know about the different implementations, but rather the system somehow chooses the correct implementation, probably based on constraints defined by the implementation. If this is true, then clients of polygon can only declare variables to be of type polygon, and not of type rectangle. (In fact, I think it would be a mistake to call these alternative implementations "classes".) Multiple implementations support the definition of algorithms of varying efficiency, but offer no client control over which implementation is chosen. (There may be faster algorithms for drawing rectangles than other polygons, but the client can't say they only want to consider rectangles.) Subtyping offers the client finer-grained control over the desired semantics, but (in strong type-checking languages) restricts the programmer's flexibility in defining subtypes. (The client can restrict a variable to be a rectangle, but now the programmer can't define add_vertex on polygons.) I suspect there are uses for both solutions. -- Barbara Staudt Lerner Deparment of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 blerner@cs.umass.edu