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: 103376,12c1e4936587932e X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news2.euro.net!amsnews11.chello.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: overriding in private part Date: Fri, 3 Oct 2008 21:28:43 -0500 Organization: Jacob's private Usenet server Message-ID: References: <45b4a4cc-13f5-4175-9061-9c962e32d762@64g2000hsm.googlegroups.com> <47e26a8d-d104-46c5-b841-667f6e556792@w7g2000hsa.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1223087378 7743 69.95.181.76 (4 Oct 2008 02:29:37 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 4 Oct 2008 02:29:38 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:7952 Date: 2008-10-03T21:28:43-05:00 List-Id: "Robert A Duff" wrote in message news:wcc1vyxwhge.fsf@shell01.TheWorld.com... > Adam Beneschan writes: > >> I shouldn't have said "solve". It *partially* solves the problem, in >> that if the programmers use "overriding" and "not overriding" >> consistently on everything, it won't let you write a program that has >> an unexpected result of the sort Maxim ran into. > > I think you should say "overriding" wherever it's legal, > but never say "not overriding". And use a compiler that > warns on missing "overriding" -- such as a recent GNAT > with the -gnatyO switch. I agree with Adam; after all, there is a reason that "not overriding" exists. I'm curious as to why you think it shouldn't be used. If you write a routine that you do not expect to override something, and it does anyway, you have a problem (because you could be called from a dispatching routine with a completely different purpose, and conceivably different preconditions and postconditions). I think you'd like to know about that problem. There are cases where you can't use either indicator (where the overriding happens "late"), but those usually indicate a program structuring issue (routines are being hidden in the root types that ought to be visible, or the child types are making routines visible that should be private). And in such cases I think it is important to document why no indicator was given with a comment. I wanted indicators to be allowed on all subprograms in order that I could enforce a rule of "no indicator" -> style violation, but that got voted down (they're only allowed on primitive subprograms). I still think that was a serious mistake (it's weird to have to leave out indicators on class-wide routines, for instance). Randy.