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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/05/13 Message-ID: #1/1 X-Deja-AN: 154548397 sender: news@assip.csasyd.oz references: organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-13T00:00:00+00:00 List-Id: Tucker Taft writes: :Richard Riehle (rriehle@nunic.nu.edu) wrote: :: :: [references for Liskov substitutability] Thanks for these. [...] :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. Because Eiffel invariants are ANDed with ancestor invariants, they become successively tighter in descendants. Doesn't this fit the bill? :: Richard Riehle : :-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ :Intermetrics, Inc. Cambridge, MA USA /// Don. (o o) =-=-=-=-=-=-=-=oOO=-(_)-=OOo=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au