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-31 02:53:57 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stueberl.de!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: Thu, 31 Jul 2003 11:58:41 +0200 Message-ID: <91nhivgoeparbpt1984prf1o09sos9f9p5@4ax.com> References: <1059416297.548253@master.nyc.kbcfp.com> <1059486223.780998@master.nyc.kbcfp.com> <8tucivgbh5hkuicrpdeuavau8muf6a9mrh@4ax.com> <1059496557.747795@master.nyc.kbcfp.com> <1059583115.463164@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 1059645235 23017027 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:41065 Date: 2003-07-31T11:58:41+02:00 List-Id: On Wed, 30 Jul 2003 12:38:35 -0400, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> 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. > >We need to look at this without using common English words >that will cause confusion: > > type Base is ...; > function Affect(X : Base) return Base; > type Derived is new Base ...; > function Affect(X : Derived) return Derived; > >Now if I have a Derived object attached to a Base'Class >reference, and I make a dispatching call, the Derived >Affect will be called, will return a Derived object, and >since a Derived object is a Base object, substitutability >is satisfied. No it isn't. You forgot semantics. LSP is all about semantics. The problem is that Affect returning Derived just cannot be implemented in Cricle/Ellipse case. This problem appears each time a derived type is a specialization of the base. Specialization breaks out-methods. Covariant result is a case of out-method. Period. > If the Derived type, or the Base type, is >supposed to maintain certain invariants but the methods >fail to do that, then the methods are in error, but that >has nothing to do with LSP. What does it mean to "be in error"? The contract of Base does not mention "being in error". So it violates the contract and thus LSP. >> ---- LSP-abstinence-syndrome >> Hey, "computer circles" are not "computer ellipses"! > >This is the correct answer. Yes, but it does not imply that Circle shall not be a subtype of Ellipse. In a real system it will, because code reuse is more important than far-fetched absolute LSP. It is clear that an absolute substitutability cannot be enfoced by any means. The real solution is a context-dependent substitutability and type systems helping in checking it as much as possible. >> 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. > >Nonsense. The only unsoundness here is the confusion between >abstract notions and and how they map into computer code. Your >use of the words "Ellipse" and "Circle" and "Resize" demonstrates >this. What is the computer-ellipse? If it is an object which has >independently resizable axes, and a computer-circle does not, then >a computer-circle is not a computer-ellipse, and can't be used in >places where computer-ellipses are expected. On the other hand, if >a computer-ellipse is an immutable object with a pair of axis sizes, >then a computer-circle can be written to fit that interface as well, >and can be used where a computer-ellipse is expected. This is one of many ways of defending [absolute] LSP. Surely if you are dealing with something so airy which cannot be expressed mathematically, then you simply cannot disprove it mathematically. (:-)) >This is all perfectly obvious and has been talked about over and >over again. It's simply a matter of asking what operations a base >type supports, and whether a derived type can support all of the >same operations. Any notion that derivation within computer code >must somehow model abstract notions of the real world is wrong, >and leads into confusion and error. This exactly means to be mathematically unsound. >> Ada does this. It is a class-wide argument. > >Does it? Do you have an example? I'm not sure that it's the >same thing, but we'll see. Class-wide arguments are not controlled, they are not inherited when you derive. Because a class-wide argument is a closure of the set of all derived types. type Base is tagged ...; procedure Foo (X : Base'Class); type Derived is new Base ...; -- Foo is same for Derived and it is not inherited One could say that class-wide arguments are contravariant, but this would be imprecise, because no type conversion to the base type happens. However, the effect is same [as long as redispatch supported through an embedded type tag] > > 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. > >I forget. Does Ada let you pass a Positive object to a >procedure expecting an Integer out parameter, Yes. > and range >check the assignment, or does it forbid such a call? If >it's the former, then LSP is in fact preserved, in that >the same set of operations are permitted. It is so: 1. if Constraint_Error is a part of the contract of the procedure then LSP is preserved with this regard. As I said to add all imaginable exceptions to all contracts is a possible way. Unfortunately it is great burden and it erodes the idea of checkability. 2. if Constraint_Error is not in the contract. then LSP is violated. >The operation >may throw an exception, but it's present. That's the same >thing as implementing Circle.Resize and having it throw >if the two axes are not specified to bethe same size. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de