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,efe03f20164a417b
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-03-27 18:20:08 PST
Path: 
 nntp.gmd.de!Germany.EU.net!EU.net!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!epflnews!dinews.epfl.ch!di.epfl.ch!Robb.Nebbe
From: Robb.Nebbe@di.epfl.ch (Robb Nebbe)
Newsgroups: comp.lang.ada
Subject: Child packages
Date: 27 Mar 1995 09:59:45 GMT
Organization: Ecole Polytechnique Federale de Lausanne
Sender: nebbe@lglsun3.epfl.ch (Robb Nebbe)
Distribution: world
Message-ID: <1995Mar27.115304@di.epfl.ch>
References: <3kbkm1$41o@miranda.gmrc.gecm.com>
 <3kcflv$164a@watnews1.watson.ibm.com>
 <EACHUS.95Mar23113811@spectre.mitre.org>
 <3ku7us$117l@info4.rus.uni-stuttgart.de>
NNTP-Posting-Host: lglsun3.epfl.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 1995-03-27T09:59:45+00:00
List-Id: <comp.lang.ada>

In article <3ku7us$117l@info4.rus.uni-stuttgart.de>, ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:
|> Robert I. Eachus (eachus@spectre.mitre.org) wrote:
...
|> :     Of course, and the reason for posting this, is that one needed
|> : form of the pragma is "pragma Child_Units(None);" or "pragma Child_Units;"
|> : I perfer the second form, what do the rest of you think?
|> 
|> I would not recommend that whole direction because
|> one of the strengths of the child feature is exactly the fact,
|> that the parent need not be touched further on.
|> For Ada200X, the abs private part may be more convenient (if any)
|> but, imho, this overburdening of the language is superfluous.

If you think of child packages as module extension then the logical place
to deal with issues like this is with other version control questions.

I don't see how something like who can add a child package is fundamentally
any different that who can modify a package. In my opinion a pragma
to deal with this situation would do more harm than good.

Robb Nebbe