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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 09/10/2017 00:52, Victor Porton wrote:
> The following does not compile:
> 
> $ gnatmake -gnat2012 test
> gcc-7 -c -gnat2012 test.adb
> test.adb:18:20: subprogram "X" overrides inherited operation at line 21
> gnatmake: "test.adb" compilation error
> 
> 
> -- 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;
> 
> 
> So private part badly influences what can and what can and what cannot be
> done in the public part. Private must be private!

Yes, but it does not apply here. B has full visibility on B_Type. There 
is nothing private about how B is going to implement B_Type. An 
implementation that inherits from A_Type is incorrect when X is not from 
the class (not overriding) and the compiler dully states that.

When you qualify X as type-specific (not overriding) you wanted exactly 
that sort of check.

Note that the situation would be different if A were a private package. 
Then of course the public part of B should be free to declare X 
independently on private A_Type. Then there would be a problem with 
clients that could see both A and privates of B. But AFAIK this kind of 
scenario is impossible to construct.

> Really bad!

I don't see anything bad here. There are bad cases, e.g. private 
interfaces and others, but this one is OK to me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de