Re: Child packages [nn,pedo,incest,cons]

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

In article <1994Oct17.091621@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:

 > But you have to want to shoot yourself in the foot. I would think it
 > would be almost impossible to "accidently" declare a child package
 > and muck around with private information.

   Never underestimate stupidity, you can't overestimate it.

   "Against stupidity, the Gods themselves contend in vain." Schiller(sp?)

   You have to know why it is a bad thing. There are no warning signs
posted.  And I don't expect people to spend lots of effort adding
comments to package specifications explaining what catastrophes can be
created by illegitimate children.

   Also, it is possible to write packages so that illegitimate
children are inherently safe.  It takes a little more effort, but
since it is possible many coding practices will favor it.

   But look what happens when someone whose entire experience was in
such an envirionment moves to a company with different practices.

   Maybe what we need are a few "stickers."  One line comments to be
put as the first thing in a private part and explain the relative risk
of illegitimate children:

   "This package is designed to freely allow child units to be added."

   "Any child unit which updates state in this private part must
observe the locking protocol."

   "This subsystem was not designed to allow addition of child units.
User defined child units may be broken by new implementations of the
subsystem."

   "This package will break in the presence of unanticipated child units."

    I guess I'll have to start doing that for Ada 9X code.  They
certainly belong in any published code (including in RM9X) but there
is a lot of Ada 83 code around without the stickers on it.

    (I'll turn this into an "official" 9X comment.  The private parts
of all the language defined packages say:

    private
      ... -- not specified by the language
    end...

    At a minimum, either paragraphs 1.1.3(18-19) should specify that
not specified is the same as unspecified, or all those comments shoul
change.  But I think the best idea would be to also explicitly define
for which language defined packages, if any, user defined children
should not take advantage of visibility into the private part.  (As I
indicated, and I hope as implementors will do it, it should be
possible to allow (implementation dependant) user defined child units
for most language defined packages without risk.)

--

					Robert I. Eachus

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