Re: Derived private interface

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

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net...
...
> If a programmer's intent has been to express overriding status, but, when
> trying to do so, he or she did not understand the full set of rules
> that restrict the set of permissible places for overriding_indicator,
> the compiler's complaint may generate anger more than anything else.

If the programmer doesn't understand the model of overriding in Ada, they 
are going to be disappointed. It's better that the compiler complain than 
silently doing the wrong thing.

...
> That is, in this programming situation involving non-overriding
> operations, the [not] overriding_indicator does not entail measures
> against the effects of typos (the feature's purpose as stated in the RM).

I have no idea what you are talking about. The feature definitely prevents 
problems with the effect of typos; of course, if you use it when there is no 
overriding going on, you'll have problems.

> But it may well create confusion.  Even when some lengthy formal
> exegesis will permit putting the blame on the programmer, this does
> not seem helpful.  I can't think this has been an intent, either.

If you don't understand what you are doing, you are going to have problems.

> The LRM rules regulating overriding_indicator seem to have been
> derived form Ada's O-O logic and visibility.

What else would it derive from?

> Not so much from the
> more general programming situation where any indicators would
> instead cater to programmers' intentions, IMHO.

It corresponds exactly to the programmer's intentions, so long as those 
intentions are based on the RM definition of overriding and not some other 
imagined version of the rules.

> Example:
>
...
>    55.     package C4 is
>    56.
>    57.         type T1 is private;
>    58. --  Overriding status is not known.  Should we care
>    59. --  in this case, for a type that is simply private?
>    60.         procedure Op (X : in out T1);
>    61.
>    62.     private
>    63.         type T1 is new P1.T1 with null record;
>    64.     end C4;

You should not use any indicators in this case, as the type in question is 
not a derived type (which for this purpose includes type extensions and 
private extensions). Only derived types inherit anything, so the use of any 
indicators is wrong/misleading. It should be noted that I had wanted to be 
able to use "not overriding" everywhere, but I was overruled.

The private type demonstrates a serious flaw in Ada that unfortunately we're 
stuck with. You should not be able to have a routine that is declared in the 
visible part be overriding in the private part. That should be strictly 
illegal. (OTOH, it is be OK to override solely in the private part.) 
Operations that are visible and are inherited should be visibly inherited.

The work we've been doing recently with contracts (preconditions, 
postconditions, and the like) demonstrate this; you will have all sorts of 
logical problems when the visible contracts on the specification aren't 
appropriate for those on the overriding. You would be many times better 
served to visibly inherit the routine (along with the contracts), either by 
using an interface or by visibly deriving from P1.T1, or to avoid 
inheritance altogether (by using a record with a component of P1.T1.)

Note also that this sort of structure prevents the use of C4.T1 by the 
client in class-wide operations of P1.T1. That is usually a bad thing 
(requiring duplication of operations in order to provide equivalent 
functionality). Sometimes people do this on purpose, in an attempt to 
"eliminate" operations from an extension. But "eliminating" operations 
violates all of the theory about OOP, and generally means that a 
restructuring of your "object" types is needed.

To summarize: this is a bad case that shouldn't have been allowed by Ada in 
the first place -- the problem is with Ada allowing it, not with the use of 
indicators with it.

(You'd have had a better case had you shown examples involving generics. 
Those caused all of the problems that led us to abandoning the "always use 
indicators" restriction.)

                                                   Randy.