Re: 'Protected' abstract subprograms

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

On Tue, 14 Jan 2014 18:36:13 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:on1zhsdlciqw.70mg9osrtb80$.dlg@40tude.net...
>> On Mon, 13 Jan 2014 21:45:24 -0600, Randy Brukardt wrote:
>>
>>> Yes, but that would require some way of specifying that the private type
>>> cannot be extended anywhere *other* than a child of the package 
>>> containing
>>> the private type.
>>
>> Doesn't
>>
>>   type T is private;
>>
>> already do? It could be reused like
>>
>>   type T is private [abstract] new ... with ...;
> 
> I don't understand. The OP would like to restrict the extensions of private 
> type T to child packages, because those already can "see" that overriding of 
> private abstract operations is needed. That would require some additional 
> marking of the private type T in the specification of a package to avoid 
> breaking privacy (legality rules cannot depend on the contents of the 
> private part).

Hmm, of course they can and do. Do you mean legality of public part not
depending on the legality of private parts? Even they do.

Regarding private types, I mean that when T is declared private one cannot
extend it publicly but still can do privately. The following is legal Ada,
AFAIK:

   type T is limited private;
private
   type T is new Ada.Finalization.Limited_Controlled with null record;
   type S is new T with null record;

There is no obvious harm to allow:

   type T is abstract limited private;
private
   type T is abstract new Ada.Finalization.Limited_Controlled
      with null record;
   procedure Foo (X : T) is abstract;

and, more useful:

   type T is private abstract new Ada.Finalization.Limited_Controlled
      with private;
private
   type T is abstract new Ada.Finalization.Limited_Controlled
      with null record;
   procedure Foo (X : T) is abstract; -- OK

Because T is publicly private it cannot be extended publicly and so allowed
to have private abstract operations.

[Not that I propose this sort of language extension]

>>> As I said last week, Ada takes privacy very seriously,
>>
>> Moderately serious I would say. In numerous cases privacy does not hold.
>> Worse is that frequently privacy cannot be imposed or requires serious
>> changes in the structure of types.
> 
> Privacy (like other visibility rules) is a compile-time construct only.

Yep, that's what I meant under "cooperative" privacy. For many
applications, and the number of is growing rapidly, a "non-cooperative"
privacy is needed as well.

> Run-time features (like representation or dynamic checking) are not affected 
> by privacy (or visibility). I'm not aware of any cases where privacy does 
> not hold at compile-time - it is taken *very* seriously by Ada.

Just one trivial example of slack privacy. You cannot hide default values:

   type T is private;
   procedure Foo (X : T := V);
private
   type T is ...

Should have been something like:

   type T is private;
   procedure Foo (X : T := <>); -- The value is deferred
private
   type T is ...
   for Foo'Default (X) use V; -- Here it is, whichever syntax you prefer

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