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

[bobduff@dsd.camb.inmet.com (Bob Duff)]

In article <EACHUS.94Oct17115240@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>   Never underestimate stupidity, you can't overestimate it.

Language rules can't possbily protect against stupidity (or gross
negligence) in any case.  So why bother trying?  The language rules
should make Doing Good easier than Doing Evil.  But the language
designer can't possibly prevent the latter, nor even know for sure
what's Evil in a given situation.

>   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."

This sort of comment might be useful, but how does it differ from
comments addressed to maintainers who need to change the package itself?
"-- If you change this code, be sure to obey the locking strategy."
Etc.  Think of adding a child as similar to changing the parent package
itself -- you're adding functionality to the abstraction, and you need
to know what you're doing lest you break something.

>    (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.

Sorry Robert, but I'm not going to say in the RM that "not" = "un".
It's not our job to teach people the rules of the English language.

> ...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.)

Whether or not an implementation allows the user to extend language
defined packages is defined by the implementation.  And, since the
private parts of those packages are not specified, the meaning of such
children is not necessarily portable.  Seems pretty obvious -- I don't
see any need for additional verbiage in the RM.  There's enough verbiage
there as it is.  :-(

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)