Re: overriding in private part

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wcc1vyxwhge.fsf@shell01.TheWorld.com...
>> Adam Beneschan <adam@irvine.com> 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