Re: Visibility of Indexing aspects

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

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:f923e960-d3de-4f65-91c6-bbf0a898d2f8@googlegroups.com...
> On Wednesday, July 25, 2018 at 6:12:24 PM UTC-6, Randy Brukardt wrote:
...
>> Sounds like babble to me. What's used by the client has to be public,
>> period.
>
> But this is legal:
>
> Package K is
>  Type Example is private;
> Private
>  Type Example is null record;
>  For Example'Size use 4;
> End K;
>
> Package J is
>  Type Hex is range 16#0#..16#F#
>  with Size => 4;
>
>  Type Ex_2 is record
>    Item_1 : Hex;
>    Item_2 : K.Example;
>  end record
>  with Size => 8;
>
> End J;

Yes, and that's a significant bug in Ada. Ada excepts representational 
things from privacy rules, and that causes a variety of problems. I would 
argue that if you want to explictly use the size of something, then it needs 
to have been specified visibly.

But like seemingly everything, that's too incompatible to do now.

...
> But that's not the issue that is being cited in the original post.
Surely: but it was one of the issues that Dan'l was writing a novel about.

> The issue is that all the indexing-attributes are declared/used in the
> private part and are [apparently] being used in the publicly visible part.
>
> Is this correct?
> Arguments could be made in either direction:
> (for-allowing) This allows the public declaration to be kept clean of
> generally non-relevant details; much like declaring stream input/output
> functions needn't be made explicitly public to work (due to the stream
> attributes being accessable).

Surely, but the availability of the core operation is even more important. 
Stream attributes work much like overriding; the actual body called is 
determined by the definition in the private part, but there always is a body 
(whether something is defined in the private part or not).

More generally, that model works for any operation that is *visibly* 
available. Stream attributes, inherited subprograms, etc. It doesn't work 
for operations which are being defined for the first time and aren't 
available by default (iteration, indexing, hopefully literals, etc.)

One could imagine having an extra declaration that some indexing is going to 
be provided in the private part. That would be pretty messy (since the type 
of the index(s) would have to be provided along with existence of the 
operation) but it could be done. We just didn't see any reason to bother 
with doing it, since typically one wants to be able to use the long-hand 
form (that is, the explicit function calls) in some cases. (You might not 
want to actually retrieve the element, for instance.)

> (for-disallowing) The indexable interface may not be intended for use 
> outside of
>the PRIVATE visibility space (BODY, children's private, children's body).

Correct; you want to be able to have the ability to define such things only 
for private use.

                                    Randy.