From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca.giganews.com!nntp.giganews.com!news.glorb.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: 'Protected' abstract subprograms
Date: Tue, 14 Jan 2014 18:36:13 -0600
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <lb4l5t$299$1@loke.gir.dk>
References: <839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com>
 <lapsb1$k1l$1@loke.gir.dk>
 <b7ef903a-26f8-4cbc-b137-0f35fe5be406@googlegroups.com>
 <lb2bsl$phh$1@loke.gir.dk> <on1zhsdlciqw.70mg9osrtb80$.dlg@40tude.net>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: loke.gir.dk 1389746173 2345 69.95.181.76 (15 Jan 2014 00:36:13 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 15 Jan 2014 00:36:13 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: number.nntp.dca.giganews.com comp.lang.ada:184419
Date: 2014-01-14T18:36:13-06:00
List-Id: <comp.lang.ada>

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

...
>> 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. 
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. (Note that 
child packages are considered part of their parent for visibility, including 
privacy -- you are waiving privacy when you use them -- a good reason to 
avoid them unless truly needed.)

                                            Randy.