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: a07f3367d7,158ce2376534c35d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Wed, 6 Jul 2011 14:45:25 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1309981528 31602 69.95.181.76 (6 Jul 2011 19:45:28 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 6 Jul 2011 19:45:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Xref: g2news1.google.com comp.lang.ada:20104 Date: 2011-07-06T14:45:25-05:00 List-Id: "Georg Bauhaus" wrote in message news:4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net... ... > If a programmer's intent has been to express overriding status, but, when > trying to do so, he or she did not understand the full set of rules > that restrict the set of permissible places for overriding_indicator, > the compiler's complaint may generate anger more than anything else. If the programmer doesn't understand the model of overriding in Ada, they are going to be disappointed. It's better that the compiler complain than silently doing the wrong thing. ... > That is, in this programming situation involving non-overriding > operations, the [not] overriding_indicator does not entail measures > against the effects of typos (the feature's purpose as stated in the RM). I have no idea what you are talking about. The feature definitely prevents problems with the effect of typos; of course, if you use it when there is no overriding going on, you'll have problems. > But it may well create confusion. Even when some lengthy formal > exegesis will permit putting the blame on the programmer, this does > not seem helpful. I can't think this has been an intent, either. If you don't understand what you are doing, you are going to have problems. > The LRM rules regulating overriding_indicator seem to have been > derived form Ada's O-O logic and visibility. What else would it derive from? > Not so much from the > more general programming situation where any indicators would > instead cater to programmers' intentions, IMHO. It corresponds exactly to the programmer's intentions, so long as those intentions are based on the RM definition of overriding and not some other imagined version of the rules. > Example: > ... > 55. package C4 is > 56. > 57. type T1 is private; > 58. -- Overriding status is not known. Should we care > 59. -- in this case, for a type that is simply private? > 60. procedure Op (X : in out T1); > 61. > 62. private > 63. type T1 is new P1.T1 with null record; > 64. end C4; You should not use any indicators in this case, as the type in question is not a derived type (which for this purpose includes type extensions and private extensions). Only derived types inherit anything, so the use of any indicators is wrong/misleading. It should be noted that I had wanted to be able to use "not overriding" everywhere, but I was overruled. The private type demonstrates a serious flaw in Ada that unfortunately we're stuck with. You should not be able to have a routine that is declared in the visible part be overriding in the private part. That should be strictly illegal. (OTOH, it is be OK to override solely in the private part.) Operations that are visible and are inherited should be visibly inherited. The work we've been doing recently with contracts (preconditions, postconditions, and the like) demonstrate this; you will have all sorts of logical problems when the visible contracts on the specification aren't appropriate for those on the overriding. You would be many times better served to visibly inherit the routine (along with the contracts), either by using an interface or by visibly deriving from P1.T1, or to avoid inheritance altogether (by using a record with a component of P1.T1.) Note also that this sort of structure prevents the use of C4.T1 by the client in class-wide operations of P1.T1. That is usually a bad thing (requiring duplication of operations in order to provide equivalent functionality). Sometimes people do this on purpose, in an attempt to "eliminate" operations from an extension. But "eliminating" operations violates all of the theory about OOP, and generally means that a restructuring of your "object" types is needed. To summarize: this is a bad case that shouldn't have been allowed by Ada in the first place -- the problem is with Ada allowing it, not with the use of indicators with it. (You'd have had a better case had you shown examples involving generics. Those caused all of the problems that led us to abandoning the "always use indicators" restriction.) Randy.