Re: Derived private interface

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 7/6/11 9:45 PM, Randy Brukardt wrote:
> "Georg Bauhaus"<rm.dash-bauhaus@futureapps.de>  wrote in message
> news:4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net...
> ...

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

(About what you explain later on: that we should avoid overriding_indicators
when they create 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.

This topos (of which "Stupid!" seems a possible paraphrase) copies, almost
exactly, that of a zealot defending C's flaws, fiercely. ;-)

But, seriously, as they reportedly say in ARG circles, almost no one
understands Ada.  Therefore, if a substantial amount of understanding
is necessary in order to use indicators properly, there is something
wrong somewhere, IMHO.  You have pointed to flaws and alternative solutions,
Dmitry has hinted at syntactical means of classifications, I think.

>> 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?

Like in the days that led to Ada: language features should
meet a requirement. To establish the requirements, you would,
quite naturally, not be taking most input from the language
not defined yet.  In the case leading to overriding_indicator,
the requirements seems to include technicalities with typos
in Ada programs ...


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

And here's a point: when I use Ada syntax, I like to think that
its purpose is to express my intentions with regard to the next
thing, which is describing one part of the problem and its
solution in Ada.  To illustrate, when I write "type" or
"procedure" or "loop", then I want the next thing to be a type,
a procedure, or a loop.  When I write "overriding", I do not
influence in any way what the next thing will be (overriding or
not), as this is a consequence of language rules.

The purpose of syntax should not be to clarify
my understanding of the Ada language.  Or is a program an exam
that tests my understanding of Ada's O-O features?

But OK, seen as a use case of syntax, "overriding" as a keyword
mirrors "limited" in that there is permission to use  and repeat
"limited" in a type's definition even when it is limited anyway.
I like it.

Does "limited" create comparable problems, though?

Your comment above is about permissible programmer intentions,
if I may say so.  Just for contrast, C version:
int behavior near INT_MAX corresponds exactly to the programmer's
intentions, so long as those intentions are based on the standard's,
the compiler's, and the platform's definition (or not) of int
and not some other imagined integers.

While this is correct, it doesn't prevent the bi-weekly CVE
caused by int.


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

Arguably (and I'm not sure I like the pattern implemented using
inheritance), to remove the operations from a type in the visible
part (by not making it visibly inheriting) would serve to establish
an adapter. I don't see the problem with theory about OOP:

- there is then a different type that hides the information that
   it privately inherits,

- clients are prevented form deriving from the visible type.


> (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.)

So I was right to not even try, based on a gut feeling. :)