Bad influence of private part on what subprograms can be defined

Bad influence of private part on what subprograms can be defined

[Victor Porton]

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!

Also note that if we would not use "not overriding" then changing the 
ancestor in the private part would have the potential to influence semantics 
of the program! (not in the above code as both procedures X are null, but in 
principle)

Can anything be done around this issue?

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.

Really bad!

-- 
Victor Porton - http://portonvictor.org

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

[Dmitry A. Kazakov]

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

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

[AdaMagica]

Dmitry is correct. The programmer of B has full control about how he is going to implement the type and its operations. There is not any surprise for him about whether an operation would be overriding or not. If he doesn't want X to be overriding, he has to choose a different name. In the latter case, a user of B will not see (will not be able to directly call) the inherited operation although it exists.

  package B is
    type B_Type is tagged private;
  --procedure X (Object: B_Type);  implicitly defined
    procedure Y (Object: B_Type);
  private
    type B_Type is new A.A_Type with null record;
  end;

  package body B is
    procedure Y (Object: B_Type) is
    begin
      X (Object);  -- indirect call of inherited X
    end;
  end;

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

[AdaMagica]

Place of implicit declaration corrected:

  package B is
    type B_Type is tagged private;
    procedure Y (Object: B_Type);
  private
    type B_Type is new A.A_Type with null record;
  --procedure X (Object: B_Type);  implicitly defined here
  end;

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

[Randy Brukardt]

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