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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f039470e8f537101 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-29 01:39:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Non-philosophical definition of Eiffel? Date: Tue, 29 Jul 2003 10:43:57 +0200 Message-ID: References: <3F200AD0.94F79098@adaworks.com> <7u9Ua.13412$634.10307@nwrdny03.gnilink.net> <3F215120.1040706@attbi.com> <1059151910.357790@master.nyc.kbcfp.com> <1059416297.548253@master.nyc.kbcfp.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1059467960 21908230 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40932 Date: 2003-07-29T10:43:57+02:00 List-Id: On Mon, 28 Jul 2003 14:18:17 -0400, Hyman Rosen wrote: >Alexander Kopilovitch wrote: >> So, is there a definitive book about Eiffel programming language, but without >> too many pages about Design By Contract? > >Go right to the horse's mouth, _Object Oriented Software Construction_ >by Bertrand Meyer. In my opinion, the huge error made by Eiffel is to >have covariant argument types for inherited methods, and this as an >error from which the language has never recovered. How could it be otherwise? [If the argument type is contravariant, then the subroutine is not a method in this argument => it is not inherited.] >For those unfamiliar with the concept, Eiffel allows a derived class >to override an inherited method with a method whiach takes a more >restricted argument type. This obviously causes huge correctness >issues, since at any call using a base object you may be committing >a type violation that you are not even aware of! The Eiffel people >have spent years trying to figure out ways around the problem while >still keeping the original design. That's not Effel's problem. This a problem of type specialization which inevitably breaks out-methods. Nothing can be done about it. BTW, generalization breaks in-methods. In short, the notion of absolute substitutability (the way many are treating LSP) is useless absolutely. subtype Positive is Integer range 1..Integer'Last; is a specialization, and it breaks LSP, and we do not care. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de