Re: Derived private interface

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

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net...
> On 7/6/11 6:34 AM, AdaMagica wrote:
>> I should have written
>>
>>    overriding procedure Doit (X: access Derived_Class);
>
> Instead of sprinkling the program with overriding indicators,
> shouldn't it be normal for a compiler to detect the status of
> a subprogram WRT overriding?

Sure, but what the compiler decides and what the programmer expects are very 
often different. The intent of indicators is to tell the compiler what the 
programmer is expecting.

> (It is, I think, and not just in
> Ada.) Consequently, programmers would mark the opposite case.
> They'd write "not overriding" only if a subprogram is really
> intended to not be overriding.

That would work if the compiler rejected routines that were not overriding 
unless "not overriding" appears. But Ada doesn't work that way (because it 
inherited a bad model from Ada 95).

Routines that didn't override when they were expected to cost us more than 
100 hours of debugging when we building Claw. Typos, changes to the root 
classes, and interactions with Ada's visibility rules all caused routines to 
not override when they should have. Overriding indicators were invented 
specifically to address this problem; the original intent was to include a 
state where it was illegal to override unless the indicator was provided. 
(Semantic issues with that caused it to be abandoned.)

"Not overriding" is far less important.

> Premises:
> - A subprogram is an overriding subprogram in most cases.
> + I.e., a subprogram following a type declaration is usually
>   intended to override. Here, "usually" refers to OOD
>   being  ubiquitous.

That is only true for derived types (including type extensions); it's never 
true for any other kind of type.

> - Idiomatic use will suggest to place non-overriding subprograms
>   in nested packages (factories, for example).

That makes no sense, as any time an extension adds new operations you will 
want those to be primitive and inherited in further extensions. Claw has a 
lot of such operations.

> - Compilers will warn in any case whenever they detect
>   a subprogram that looks suspicious.

That's not possible in any reasonable way. It's quite common to add 
overrloaded operations with additional/different parameters in an extension. 
As a result, Janus/Ada has no such warnings, because we couldn't find 
anything that wouldn't be "crying wolf" more often than it would be telling 
something useful. And proper use of indicators is better anyway, because the 
program is rejected if wrong.

                                           Randy.