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 Path: g2news1.google.com!news4.google.com!feeder3.cambrium.nl!feeder5.cambrium.nl!feed.tweaknews.nl!68.142.88.75.MISMATCH!hwmnpeer01.ams!news.highwinds-media.com!news.astraweb.com!newsrouter-eu.astraweb.com!news.tele.dk!news.tele.dk!small.news.tele.dk!lnewsinpeer00.lnd.ops.eu.uu.net!bnewsinpeer00.bru.ops.eu.uu.net!emea.uu.net!newsfeed.arcor.de!newsspool3.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="iso-8859-1" Content-Transfer-Encoding: 8bit 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> <1p717twnydnre$.1j6izygvqo832.dlg@40tude.net> <1180425803.422075.100090@o5g2000hsb.googlegroups.com> Date: Tue, 29 May 2007 15:18:58 +0200 Message-ID: NNTP-Posting-Date: 29 May 2007 15:16:43 CEST NNTP-Posting-Host: 43bc2c26.newsspool3.arcor-online.net X-Trace: DXC=HbH^c_R4ORff1oJaJ0@dmgMcF=Q^Z^V3h4Fo<]lROoRaFl8W>\BH3Yb1GbNE\e:ZVdDNcfSJ;bb[eFCTGGVUmh?dLK[5LiR>kgbfdgDEh\3Hcc X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15965 Date: 2007-05-29T15:16:43+02:00 List-Id: On 29 May 2007 01:03:23 -0700, Maciej Sobczak wrote: > On 27 Maj, 12:04, "Dmitry A. Kazakov" > wrote: > >> 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. > > OK, now I see your point. I have nothing against following this path - > assignment statement *is* special anyway. What could go wrong if we > say that assignment is not inherited? Then you will have a messy bunch of overloaded ones. There are two variants of: 1. Use of T'Class, I considered this in a previous post, it is ambiguous. 2. Non-primitive operation (ugly hack). This will not work on class-wide arguments: X : T'Class := Y; -- Illegal, ":=" isn't defined on LHS T'Class >> 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? > > Probably design issue. Character encoding can/should be a strategy > inside a String, you don't need to subclass the whole thing just for > it. There are many aspects on which you could parameterize String and > with some of them being orthogonal you could quickly end up with > milion leaf classes. So? This is exactly the reason why I want to keep them all in one class. Encoding is a constraint put on the object. It is mapped to a type to be able to implement string operations independently, for each encoding through dispatching rather than by ugly nested case-statements. And what about fixed vs. bounded vs. unbounded axis? Why a fixed string shouldn't be assigned to an unbounded one and reverse? How are you going to design such stuff without polymorphism? By cut'n'paste, as RM does? At some point they too had got tired: "... For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and Strings.Maps.Constants the corresponding wide string package has the same contents except that � Wide_Space replaces Space � Wide_Character replaces Character � Wide_String replaces String ..." (:-)) >> 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. > > Yes. That's why I say that I have never seen any reasonable hierarchy > that supports assignments. Strings above. >> There is nothing special in >> assignments. > > Yes, there is - they are generated. This is deceptive, because it > makes one think that it should all work by magic. It means that the language is unable to express assignments in its own terms. I don't want such language. In fact, the rules you propose for assignments can be expressed in Ada terms: type X is private; type Y is new Y; -- Done Don't use classes if you don't want to assign them. > Another reason why they are special is that they are intuitively > associated with some particular effects and these effects cannot be > reasonably provided in an automated way. That's why I think that > assignments of class-wide types should be forbidden. No, it is much simpler to provide multi-methods and make it consistent. The only problem Ada has with assignment is that it is a fake MD. If it were a true MD, then upon inheritance (per extension) from a tagged private T, the compiler would complain: "hey, I don't know how to assign T to S!" This would force you to override S := T in a reasonable way (existing for String) or else to rethink your allegedly wrong design. Presently Ada silently generates raise Constraint_Error, which is not good. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de