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-Thread: 103376,2ff5c149712ec0eb X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.germany.com!news.belwue.de!th!lucks From: Stefan Lucks Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle Date: Thu, 24 May 2007 13:12:56 +0200 Organization: InterNetNews at News.BelWue.DE (Stuttgart, Germany) Message-ID: References: NNTP-Posting-Host: th.informatik.uni-mannheim.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: news.BelWue.DE 1180005195 21832 134.155.91.85 (24 May 2007 11:13:15 GMT) X-Complaints-To: news@news.belwue.de NNTP-Posting-Date: Thu, 24 May 2007 11:13:15 +0000 (UTC) In-Reply-To: Xref: g2news1.google.com comp.lang.ada:15902 Date: 2007-05-24T13:12:56+02:00 List-Id: Dmitry A. Kazakov wrote: > [...] mere passing a variable as "in" does it as > well in the sense that "in T" is not an LSP-subtype of T. You are using a very broad and generalised interpretation of the LSP. My interpretation -- and I believe this is the common and usual one -- is that "X: in T" in the parameterlist of a subprogram does not deal with some "artificial" type "in T", just with "T". The "in" is part of the subprogram's contract, not a part of X's contract. So there is no conflict with LSP. > LPS is totally irrelevant as long as substitutability violation can be > detected at compile time. This is why "constant" does not worry anybody. A > method disallowing is perfectly OK, if you cannot call it. So your very broad and generalised interpretation of the LSP is totally irrelevant, except for the special case where it overlaps with the more narrow usual interpretation. Perhaps you should follow the crowd and narrow your interpretation as well? Whatever interpretation, the stuff below is right. > LSP violation becomes a problem when substitutability is indeterminable > until run-time. In may cases we still choose to live with that. Constrained > Ada subtypes is an example of. Another is multi-methods Foo (X, Y : T), > when called on different children of T. In such cases Ada adds > Constraint_Error to the interface of each subprogram and things become > "substitutable" again. Yes, that is an ugly patch. But it appears tricky to come up with a better solution ... > LSP violation is catastrophic when undetected. [...] It is bad enough if detected after lengthy testing and debugging sessions. -- Stefan Lucks (moved to Bauhaus-University Weimar, Germany) ------ I love the taste of Cryptanalysis in the morning! ------