From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Real OO Date: 1996/05/10 Message-ID: #1/1 X-Deja-AN: 154123123 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: henning.camb.inmet.com references: followup-to: comp.lang.eiffel,comp.lang.ada,comp.object organization: Intermetrics, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-10T00:00:00+00:00 List-Id: Richard Riehle (rriehle@nunic.nu.edu) wrote: : ... : Though the substitutability principle is often attributed to Liskov, : it is also given treatment in a paper from Wegner and Zdonic, : "Inheritance as an Incremental Modification Mechanism" published in : the Proceedings of the European Conference on : Object-Oriented Programming, 1988. : An important overview of this subject is Cardelli and Wegner, "On : Understanding Types, Data Abstraction, and Polymorphism," ACM : Computing Surveys, Number 17, 1985. : -- ================================================================= : All that academic stuff aside, the substitutability rule is quite : useful when trying to determine whether one is organizing a set of : objects by classification or by some other mechanism. In particular, : there is a point-of-view which says one should always apply the : substitutability principle when attempting multiple inheritance. In Ada 95, the substitutability rule is almost a tautology, if you interpret it as meaning that any place where you can use A'Class, you should be able to substitute an operand of type A1'Class, where A1 is a derivative of A. Since A'Class is a proper superset of A1'Class, it is trivial to show that any procedure that works properly over all operands of "type" A'Class, will also work properly over all operands of "type" A1'Class. What this highlights, in my view, is that the substituability rule only makes sense in terms of an *explicitly* enumerated set of properties or invariants that are presumed over a given set of types. If you then want to add a new type to that set, you must be careful that the new type satisfies all of the properties/invariants presumed by the rest of the system. Clearly it is not possible to satisfy all possible properties imaginable, for example the time or space requirements of two types (and their associated operatios) will almost never be identical. If time/space is critical to the correct operation of the system (e.g. in a real-time embedded system), then you must enumerate the requirements, and verify them for each type in the set. Just saying "substitutability" doesn't really say anything, IMHO. The real issue is establishing a set of "class-wide" requirements, and then verifying them each time a new type is added to the set of types within the class (hierarchy). Eiffel tries to support this effort through class invariants, but I believe it gets tripped up a bit by the conflict between establishing useful invariants for a specific type/class in the class hierarchy, which might want to be quite "tight" so as to catch as many errors as possible, and the appropriate invariants for the entire class hierarchy, which want to be as "loose" as possible to ensure flexibility of extension. There seems to be a need to have two separate kinds of invariants -- those that apply to an individual type/class, and a separate set that get "inherited", and that apply throughout the class hierarchy. : Richard Riehle -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA