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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d10596e187e90822
X-Google-Attributes: gid103376,public
From: Tucker Taft <stt@averstar.com>
Subject: Re: Private Children
Date: 1999/06/21
Message-ID: <376E9EEB.322A3F39@averstar.com>#1/1
X-Deja-AN: 492234515
Content-Transfer-Encoding: 7bit
Sender: news@inmet.camb.inmet.com (USENET news)
X-Nntp-Posting-Host: houdini.burl.averstar.com
References: <m3bteacxb8.fsf@mheaney.ni.net> <7klja3$c0p$1@nnrp1.deja.com>
 <376E70A5.F77E558D@averstar.com> <m3yahd4bet.fsf@mheaney.ni.net>
Content-Type: text/plain; charset=us-ascii
Organization: AverStar (formerly Intermetrics)  Burlington, MA  USA
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-06-21T00:00:00+00:00
List-Id: <comp.lang.ada>

Matthew Heaney wrote:
> 
> On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote:
> 
> > To answer the question posed by this new question, the answer
> > given by Dale was correct, that private children provide "compilation
> > privacy."  If you want to allow something to be "with"ed by public
> > children's specs, but contain content that is only visible to
> > the private part of the child's spec, the following idiom works:
> >
> >    package Mostly_Private is
> >    private
> >        ... -- Declarations visible only in private part of other public
> >        ...  -- siblings
> >    end Mostly_Private;
> >
> > That is, put the entire set of declarations in the private part
> > of a public child.
> 
> I did what I think you wanted me to do, but got this error message:
> 
> gcc -c -gnatc /home/matt/p-c2.ads
> p-c2.ads:9:23: "I1" is not a visible entity of "C1"
> 
> Is this a compiler bug, or did I misunderstand what you said?
> 
> Can a package really see the private part of its sibling?  I thought
> that only your own children could see your private part.

Oops, right you are.  The "idiom" I was misremembering was actually to
create an extra level in the hierarchy, with all of the public
children made into public children of this intermediate level,
with the intermediate level spec having only a private part.
You could then use library unit renaming to hide the presence
of this intermediate level, if you wanted to.  I believe Robert
Eachus suggested this approach originally.

E.g.:
    package P.Hidden_Level is
    private
       ... -- private stuff
    end;

    package P.Hidden_Level.C1 is
      ...
    private
      ...  -- can see private decls of P.Hidden_Level
    end;

    with P.Hidden_Level.C1;
    package P.C1 renames P.Hidden_Level.C1;

Sorry for the confusion.

-Tuck

> Or did you mean for me to put I1 in the private part of P, not P.C1?
> 
> --STX
> package P is
> 
>    pragma Pure;
> 
> end P;
> 
> package P.C1 is
> private
> 
>   I1 : Integer;
> 
> end P.C1;
> 
> with P.C1;
> package P.C2 is
> 
>   I2 : Integer;
> 
> private
> 
>   I3 : Integer := P.C1.I1;
> 
> end P.C2;

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA