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!news2.google.com!news.glorb.com!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: overriding in private part Date: Sat, 04 Oct 2008 15:47:04 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <45b4a4cc-13f5-4175-9061-9c962e32d762@64g2000hsm.googlegroups.com> <47e26a8d-d104-46c5-b841-667f6e556792@w7g2000hsa.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1223149624 32084 192.74.137.71 (4 Oct 2008 19:47:04 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 4 Oct 2008 19:47:04 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:US4TEMNEFiywJq67YE0FjCc9MRk= Xref: g2news2.google.com comp.lang.ada:7960 Date: 2008-10-04T15:47:04-04:00 List-Id: "Randy Brukardt" writes: > "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. If you use a compiler that warns on missing "overriding", then you don't need to say "not overriding", because that's the default -- any subprogram that doesn't say "overriding" is not overriding. Saying "not overriding" is just noise. There is no good reason for "not overriding" to exist. If you "write a routine that you do not expect to override something, and it does anyway," then I don't agree you have a problem -- you get a warning. The warning is crucial, of course. Without that, IMHO these indicators are nearly useless. If I were designing the language from scratch, I would make missing "overriding" an error. The only reason not to do that is for compatibility with Ada 95. It's like parameter modes -- you should never explicitly say "in", because that's the default. You should explicitly say "in out" or "out". It's unfortunate that "in" is allowed, because now the language has split into three dialects -- those that say "in", those that never say "in", and those that say "in" for procedures but not functions. That's not doing anyone any favors -- the folks who write in those three dialects can't understand each other's code. > 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. And I think there are some generics-related cases, too. But these are all corner cases. By and large, you can say "overriding" when you mean it, and let "no indicator" implicitly mean "no overriding". > 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). I agree that if you want an indicator on every subprogram declaration, then forbidding "no overriding" on some non-overriding subprograms is a language design mistake. But I don't want that -- I want a safe (non-overriding) default. - Bob