Re: Bad influence of private part on what subprograms can be defined

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

"Victor Porton" <porton@narod.ru> wrote in message 
news:orea6h$1fva$1@gioia.aioe.org...
...
> -- test.adb
> procedure Test is
>
>  package A is
>    type A_Type is tagged null record;
>    not overriding procedure X(Object: A_Type);
>  end;
>
>  package body A is
>    procedure X(Object: A_Type) is
>    begin
>      null;
>    end;
>  end;
>
>  package B is
>    type B_Type is tagged private;
>    not overriding procedure X(Object: B_Type);
>  private
> --     type B_Type is tagged null record;
>    type B_Type is new A.A_Type with null record;
>  end;
>
>  package body B is
>    procedure X(Object: B_Type) is
>    begin
>      null;
>    end;
>  end;
>
> begin
>  null;
> end;

The rule of thumb for overriding indicators is that it must not be a lie. In 
package B, "not overriding" is a lie, thus it is illegal. If you remove the 
overriding indicator the package is legal.

...
> Can anything be done around this issue?

No, it's completely intentional.

> One possible solution is to allow "not overriding" (and behave as if it is
> not overriding) in public part even if it is considered overridable
> accordingly the private part (but not public part). This would make some
> non-compilable programs compilable, bit would not change semantic of
> compilable programs. So this is viable.

Not happening. This was an intentional design decision, that an overriding 
indicator must never lie at any point in the existence of the subprogram. 
And in this case, "not overriding" is a lie in the private part and body. It 
was a rather difficult decision, as there are arguments on both sides, but 
the issues that arise in generic instantiations was the deciding factor. 
Overriding indicators are purely optional, and as you've found out, there 
are some cases where you can't use either "not overriding" or "overriding". 
(That's why there isn't a restriction requiring them, which otherwise would 
be good practice.)

Note that privacy is not quite perfect in Ada; there are various other 
things that break privacy (in particular, representation clauses). 
Perfection is not possible unless one eliminates all of the utility.

                                  Randy.