Re: Child packages

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <3816h5$n3g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

 > One thing that should be emphasized about child packages (since some of
 > the posts of this thread have not been clear on this point) is that
 > child packages in no way change their parents. If you have a parent A,
 > and a child A.B, then if A.B does horrible things to the abstractions
 > in A, it still does not affect anyone who with's only package A. It is
 > only if package A.B is with'ed that the effects of the child are
 > noticable.

     Very misleading.  If a PROGRAM doesn't include any withs of a
child, the child is not part of that program and can't harm it.  But a
child unit can--even during elaboration--change hidden state in the
parent's private part.  So a child added by one portion of a large
project can harm other users of the parent package and it can be very
hard to track down.  This risk on large projects should not be
understated.  (And, yes, project management tools can control or
eliminate the problem, but these tools do not yet exist for Ada 9X.
At least tools which address this particular issue.)

     Note that on many projects the interfaces between subsystems are
specified as packages with only type and subprogram declarations in
the public part.  If 9X were only used for new projects, the simple
solution would be to outlaw state in the private part as well.  As it
is, the solution is to strongly restrict children of such packages.

     As I said, child units like fire are a net win.  But we still
need to learn how to handle them safely.  They can easily be abused.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...