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!news3.google.com!proxad.net!feeder1-2.proxad.net!usenet-fr.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 07 Jul 2011 00:05:00 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110613 Thunderbird/3.1.11 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Derived private interface 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4e14dc0c$0$6565$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 Jul 2011 00:05:01 CEST NNTP-Posting-Host: d4d6b622.newsspool3.arcor-online.net X-Trace: DXC=F>F`5XKJA8J0YVY]kmLTlDMcF=Q^Z^V3H4Fo<]lROoRA8kFejVHcJ On 7/6/11 9:45 PM, Randy Brukardt wrote: > "Georg Bauhaus" wrote in message > news:4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net... > ... >> 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. (About what you explain later on: that we should avoid overriding_indicators when they create 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. This topos (of which "Stupid!" seems a possible paraphrase) copies, almost exactly, that of a zealot defending C's flaws, fiercely. ;-) But, seriously, as they reportedly say in ARG circles, almost no one understands Ada. Therefore, if a substantial amount of understanding is necessary in order to use indicators properly, there is something wrong somewhere, IMHO. You have pointed to flaws and alternative solutions, Dmitry has hinted at syntactical means of classifications, I think. >> 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? Like in the days that led to Ada: language features should meet a requirement. To establish the requirements, you would, quite naturally, not be taking most input from the language not defined yet. In the case leading to overriding_indicator, the requirements seems to include technicalities with typos in Ada programs ... > 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. And here's a point: when I use Ada syntax, I like to think that its purpose is to express my intentions with regard to the next thing, which is describing one part of the problem and its solution in Ada. To illustrate, when I write "type" or "procedure" or "loop", then I want the next thing to be a type, a procedure, or a loop. When I write "overriding", I do not influence in any way what the next thing will be (overriding or not), as this is a consequence of language rules. The purpose of syntax should not be to clarify my understanding of the Ada language. Or is a program an exam that tests my understanding of Ada's O-O features? But OK, seen as a use case of syntax, "overriding" as a keyword mirrors "limited" in that there is permission to use and repeat "limited" in a type's definition even when it is limited anyway. I like it. Does "limited" create comparable problems, though? Your comment above is about permissible programmer intentions, if I may say so. Just for contrast, C version: int behavior near INT_MAX corresponds exactly to the programmer's intentions, so long as those intentions are based on the standard's, the compiler's, and the platform's definition (or not) of int and not some other imagined integers. While this is correct, it doesn't prevent the bi-weekly CVE caused by int. > 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. Arguably (and I'm not sure I like the pattern implemented using inheritance), to remove the operations from a type in the visible part (by not making it visibly inheriting) would serve to establish an adapter. I don't see the problem with theory about OOP: - there is then a different type that hides the information that it privately inherits, - clients are prevented form deriving from the visible type. > (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.) So I was right to not even try, based on a gut feeling. :)