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!news4.google.com!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.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: <1179953657.839272.160320@a26g2000pre.googlegroups.com> <1179991769.376381.252010@m36g2000hse.googlegroups.com> <12h6mi42jcha0.7f9vfsnihjwr$.dlg@40tude.net> <1180011507.159515.46920@o5g2000hsb.googlegroups.com> <1180079541.558215.256570@h2g2000hsg.googlegroups.com> <1180124867.710641.176330@k79g2000hse.googlegroups.com> <1k165n4jwxna3$.1mpx49xvcrc0z$.dlg@40tude.net> <1180254636.632499.3340@o5g2000hsb.googlegroups.com> Date: Sun, 27 May 2007 12:04:21 +0200 Message-ID: <1p717twnydnre$.1j6izygvqo832.dlg@40tude.net> NNTP-Posting-Date: 27 May 2007 12:04:12 CEST NNTP-Posting-Host: a0dd9c05.newsspool4.arcor-online.net X-Trace: DXC=M]No]OSdUH8RadXUBHgFh34IUK=Picmjn@MB?;DO_dG0cTn? X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15947 Date: 2007-05-27T12:04:12+02:00 List-Id: On 27 May 2007 01:30:36 -0700, Maciej Sobczak wrote: > On 26 Maj, 09:48, "Dmitry A. Kazakov" > wrote: > >>> I'm still for banning it. >> >> For this you have to make assignment contravariant (non-primitive >> operation) in one of its arguments. That would be a total mess, because it >> would require overloading assignment for each derived type. > > I don't get it. I said I would ban it. There is no "for this". :-) To ban something in the language you have to translate the ban into language terms. That could be either by syntax or by semantic rules. Because syntactically banned assignments are indistinguishable from legal ones, the only mechanics you could use for this is matching types. The types in question are from the same hierarchy (covariant). This lets mixing such types. So it *must* be contravariant to be banned = the operation (":=") will not be inherited in the argument of interest upon inheritance. >> For the same reason all signatures with a class-wide parameter are bad, >> because they lead to ambiguities in trivial cases: >> >> type S is new T with ...; >> X, Y : S; >> >> X := Y; -- S'Class x S'Class vs T'Class x T'Class? >> >> You will need some sort of dominance rules to resolve that. > > Why? Per definition/meaning of class-wide operations: they apply to *all* types from the class. > Both X and Y are of the same type above and it is not a class > wide type in the sense that no dispatching is needed here. Dispatching is about primitive operations acting on class-wide objects. Class-wide operations acting on specific objects is a way different story. >> P.S. Probably you have in mind a "stratified" assignment which statically >> checks that LHS and RHS are of the same type. > > Not necessarily. I would allow different types if the > assignment_statement is overloaded for them for those who like to > introduce sort of implicit conversions. > What I worry about is the situation where *both* dynamic types are not > known statically. This is a mess. You cannot express it in terms of the types system. So you have to roll up another formal types framework. And I don't see why it is a mess. What is wrong in assignment of UTF8_String to Wide_String, both from String'Class? The very definition of a class says that types there share class-wide and primitive operations. If that is not the case: ":=" is not shared, then either it is not a class (= don't derive! if need not) or there is no ":=" (= make it limited! if unsure). Looks much like a design problem. >> ----------- >> * Ada's assignment is doubly dispatching. The dispatching table is a >> square, the diagonal of consists of thunks: >> >> Finalize (LHS); >> bit-copy (LHS, RHS); >> Adjust (LHS); >> >> Non-diagonal elements are: >> >> raise Constraint_Error; > > Which is a run-time thingy. It's good if it's there, but I want > stricter guarantees. You can get them by just banning > assignment_statement between class-wide types. No, because that would be inconsistent. A doubly dispatching operation *has* a square table. There is nothing to do about it. You have to make it something else instead, I have listed possible variants earlier. These alternatives are mess. Hardwired rules imposed on assignments were an even bigger mess. It is bad enough that Ada has assignment defined as an statement, rather than a procedure call. There is nothing special in assignments. So your mechanism, if any, should be universally applied to all operations with multiple arguments from the same types hierarchy. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de