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-30 02:14:43 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: Wed, 30 Jul 2003 11:19:24 +0200 Message-ID: References: <1059151910.357790@master.nyc.kbcfp.com> <1059416297.548253@master.nyc.kbcfp.com> <1059486223.780998@master.nyc.kbcfp.com> <8tucivgbh5hkuicrpdeuavau8muf6a9mrh@4ax.com> <1059496557.747795@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 1059556482 23003917 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40992 Date: 2003-07-30T11:19:24+02:00 List-Id: On Tue, 29 Jul 2003 12:35:57 -0400, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> There is little sense in contravariant arguments > >OK, I just want to make sure that we're talking about >the same thing, so let me give specific examples. I'll >write in C++ terms, just because. > > struct B1 { }; > struct D1 : B1 { }; > > struct B2 > { > virtual B1 &f1(); > virtual B1 &f2(); > virtual void f3(B1 &); > virtual void f4(D1 &); > virtual void f5(B1 &); > }; > > struct D2 : B2 > { > B1 &f1(); > D1 &f2(); > void f3(B1 &); > void f4(B1 &); > void f5(D1 &); > }; > > D2 d2; > B2 *b2 = &d2; > >f1) This is ordinary overriding, with same return type. > Pretty much legal in every language. >f2) This is covariant return type. Legal in C++. This > preserves LSP, since a call b2->f2() must return a > B1 &, and a D1 & is a B1 &. Covariant return type does not preserve LSP. There is no thing which does. Everything depends on the concrete situation. Here is a famous example where covariant result breaks LSP: type Ellipse is ...; function Resize (X : Ellipse;...) return Ellipse; type Circle is new Ellipse ...; function Resize (X : Circle;...) return Circle; -- Breaks LSP, not every circle, being resized yields a circle. Typical solutions are: ----- Contravariant result type Ellipse is ...; function Resize (X : Ellipse;...) return Ellipse'Class; type Circle is new Ellipse ...; function Resize (X : Circle;...) return Ellipse'Class; ----- Exceptions Resize_Error : exception; type Ellipse is ...; function Resize (X : Ellipse;...) return Ellipse; -- May raise Resize_Error, but will not type Circle is new Ellipse ...; function Resize (X : Circle;...) return Circle; -- May raise Resize_Error, and will ---- LSP-abstinence-syndrome Hey, "computer circles" are not "computer ellipses"! The mentioned and all other "solutions" have various disadvantages. The real problem is that it is fundametally unsolvable. One could easily see that LSP is mathematically unsound, should one try to define it formally. >f3) Again, ordinary overriding, with the same argument > types in base and derived. Legal everywhere. >f4) Contravariant argument types. This also preserves > LSP, but I don't know of a language which implements > it. LSP is preserved because a call of b2->f4() can > only pass a D1 & argument, and a D1 & is a B1 &. Ada does this. It is a class-wide argument. >f5) Covariant argument types. This is Eiffel's model. > LSP is not preserved, because a call to b2->f5() > may pass any B1 &, while d2.f5() wants only a D1 &. Yes, but again, you cannot solve this. It is mother nature which decided that no positive number have an inverse. So subtype Postive is Integer ...; inevitable breaks LSP. You just have to decide what do you want, [an absolute] LSP or positive numbers. I vote for positive numbers. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de