Re: overriding in private part

["Randy Brukardt" <randy@rrsoftware.com>]

"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.

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.