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=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,990196a3d5e5eb5e
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-04-08 20:58:14 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Child packages question
Date: Mon, 8 Apr 2002 22:58:12 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <ub4pmlmg24n583@corp.supernews.com>
References: <fug4bukpc28gaqh1sci8m9ql2k1oa54ms5@4ax.com>
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
X-Complaints-To: newsabuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:22253
Date: 2002-04-08T22:58:12-05:00
List-Id: <comp.lang.ada>

Look at private packages (they're really only useful for children). See
10.1.1 in the ARM.

We put all of the bindings in Claw into private packages
(Claw.Low_Level.Windows, Claw.Low_Level.GDI, etc.). Only Claw can with
those packages; users of Claw can't access them.

            Randy.

James Ross wrote in message ...
>I have been holding off on asking because I thought I might figure it
>out myself.  I only have one Ada 95 book (I guess I oughta  buy more)
>and it is not clear on this issue.  As for looking on the net, I have
>browsed, but not extensively.
>
>Is it possible to control accessibility / visibility of packages using
>the child mechanism?
>
>For example; Car and Car.Engine -- I want the user to be able to "use"
>Car but not Car.Engine. The user could call Car.Accelerate_Mph, but
>only the Car package could call Car.Engine.Pump_More_Gas.
>
>Am I all wet here and that is NOT what child packages is all about?
>It appears that Child packages may be just a way of organizing closely
>related functionality and expanding the namespace. Thanks for any
>insights, advice, flames, etc...
>JR
>