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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada Interfaces and the Liskov Substitution Principle Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <7b9qiwewqptb$.16g096so0lqf8.dlg@40tude.net> Date: Thu, 24 May 2007 17:46:12 +0200 Message-ID: <13awcn6a95rfy.18pymw4v67avu$.dlg@40tude.net> NNTP-Posting-Date: 24 May 2007 17:44:06 CEST NNTP-Posting-Host: 9aba9fdd.newsspool3.arcor-online.net X-Trace: DXC=dETNMP4hd_W\9P[:DUn00QMcF=Q^Z^V3X4Fo<]lROoRQFl8W>\BH3YR@1;ZJ`1e=GRDNcfSJ;bb[UFCTGGVUmh?TLK[5LiR>kgR_3E8LI=U_>W X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15913 Date: 2007-05-24T17:44:06+02:00 List-Id: On Thu, 24 May 2007 16:41:45 +0200, Stefan Lucks wrote: > On Thu, 24 May 2007, Dmitry A. Kazakov wrote: > >> On Thu, 24 May 2007 13:12:56 +0200, Stefan Lucks wrote: > >>> 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". >> >> If it dealt with T, then the following program were legal: >> >> procedure Foo (X : in out T); >> >> procedure Bar (X : in T) is >> begin >> Foo (X): -- Fortunately illegal in Ada >> end Bar; > > The "X: in T" part in Bar's contract means "I (Bar) will abstain from > using certain properties X might have" (where "certain properties" are > well defined, but I am too lazy to describe them explicitely). > > When calling "Foo(X)", Bar is trying to break this contract -- and > fortunately, the compiler stops that attemtped fraud. > > Note that ther is a difference between "I will abstain from using" and "I > don't provide", A contract is imposed on both sides. It would be ridiculous to abstain from anything without another party being informed, to get something in return. > and the LSP is all about the second. The fact that inside > Bar, the programmer is forced to obey the promise made in the parameter > list is not in violation of the LSP. It makes no sense to consider type contracts which are a subject of LSP and ones that don't. What is the type of an in T parameter? It leaks, you couldn't save it. >> Yes, but then LSP should be re-formulated appropriately. And there is >> nothing automatically wrong in disallowing operations. I would like to see >> it in Ada. > > Is there any language that allows that? I am dreaming of something like > > type Base is new Some_Tagged_Type with ...; > procedure Primitive_1(...); > procedure Primitive_2(...); > > type Super is new Base with out Primitive_2; -- this is not Ada! Some years ago I proposed the syntax: procedure Primitive_2 (...) is null; > -- Super "inherits" Primitive_1 from Base, but not Primitive_2. > > B: Base; > S: Super; > > procedure Class_Wide_Base (Object: Base'Class); > procedure Class_Wide_Super(Object: Super'Class); > > Class_Wide_Base(B); -- legal, of course; > Class_Wide_Super(S); -- also legal, of course; > Class_Wide_Super(B); -- this should be legal!! > Class_Wide_Base(S); -- this should be illegal! > > This would allow to "take away" operations without actually violating LSP > (as I understand LSP). Perhaps the following would in also do the job (of > course, I could not define S of type Super, but well ...): > > type Super is interface Base with out Primitive_2; Yep, looks like supertyping. Apart from disallowing operations one also need an ability to drop the implementation (representation). So that you could make Super having members you wished, or none. The latter is stripping interfaces from concrete types. Also if the language allowed abstract record members, then that again would become just disallowing: type X is record I : Integer; ... end record; type Y is new X with ...; function Y.I return Integer is null; procedure Y.I (I : Integer) is null; -- Down with it! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de