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!feeder.news-service.com!novso.com!nerim.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 06 Jul 2011 14:59:38 +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/20110616 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> In-Reply-To: <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 06 Jul 2011 14:59:38 CEST NNTP-Posting-Host: 5805ad55.newsspool4.arcor-online.net X-Trace: DXC=26]NnbYRnc\616M64>ZLh>_cHTX3j]8`A68QlRmKS X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:20090 Date: 2011-07-06T14:59:38+02:00 List-Id: On 06.07.11 10:30, AdaMagica wrote: > On 6 Jul., 09:55, Georg Bauhaus wrote: >> On 7/6/11 6:34 AM, AdaMagica wrote: >> >>> I should have written >> >>> overriding procedure Doit (X: access Derived_Class); >> > In both cases, if the compiler suddenly complains when before > everything was OK, something in the hierarchy below the actual type > must have changed. Without those keywords, you will never be informed > and will spend hours or days debugging. Besides these cases, there are other cases that will make the compiler complain only if a programmer has placed overriding_indicators. With good reason, from his or her point of view. 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. And maybe that anger is justified. 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). 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. The LRM rules regulating overriding_indicator seem to have been derived form Ada's O-O logic and visibility. Not so much from the more general programming situation where any indicators would instead cater to programmers' intentions, IMHO. overriding_indicators are all logical and such, and I'll accept it if they cannot be designed any better. But somehow I like package C4 below a lot more than I like the others. (The error message at L.26 and L.37, taken together, are---per se---confusing, aren't they?) Example: Compilation started at Wed Jul 6 11:13:55 gnatmake -gnatwa -gnatvf -gnatl ovrd.ads gcc -c -gnatwa -gnatvf -gnatl ovrd.ads GNAT 4.7.0 20110610 (experimental) Copyright 1992-2011, Free Software Foundation, Inc. Compiling: ovrd.ads (source file time stamp: 2011-07-06 11:13:47) 1. package Ovrd is 2. 3. package P1 is 4. 5. type T1 is abstract tagged private; 6. procedure Op (X : in out T1) is abstract; 7. 8. private 9. type T1 is abstract tagged null record; 10. end P1; 11. 12. package P2 is 13. 14. type T2 is new P1.T1 with private; 15. procedure Oops (X : in out T2); 16. -- typo, possibly not caught by soundex algorithm etc, but... 17. private 18. type T2 is new P1.T1 with null record; | >>> type must be declared abstract or "Op" overridden >>> "Op" has been inherited at line 14 >>> "Op" has been inherited from subprogram at line 6 19. end P2; 20. 21. 22. package C1 is 23. 24. type T1 is private; 25. not overriding -- E! `Op` overrides invisibly (in private part) 26. procedure Op (X : in out T1); | >>> subprogram "Op" overrides inherited operation at line 29 27. 28. private 29. type T1 is new P1.T1 with null record; 30. end C1; 31. 32. 33. package C2 is 34. 35. type T1 is private; 36. overriding -- E! Overriding? Yes, but privately 37. procedure Op (X : in out T1); | >>> subprogram "Op" is not overriding 38. 39. private 40. type T1 is new P1.T1 with null record; 41. end C2; 42. 43. 44. package C3 is 45. 46. type T1 is private; 47. not overriding -- OK, not overriding in any place 48. procedure Op (X : in out T1); 49. 50. private 51. type T1 is null record; 52. end C3; 53. 54. 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; 65. 66. 67. package C5 is 68. 69. type T1 is private; 70. -- No more `Op` 71. 72. private 73. type T1 is new P1.T1 with null record; 74. overriding -- correct, overriding at this place 75. procedure Op (X : in out T1); 76. end C5; 77. 78. end Ovrd; 78 lines: 5 errors gnatmake: "ovrd.ads" compilation error Compilation exited abnormally with code 4 at Wed Jul 6 11:13:55