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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a8985ede8fe3d111 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-19 11:22:40 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.mathworks.com!noc.near.net!inmet!dsd!bobduff From: bobduff@dsd.camb.inmet.com (Bob Duff) Subject: Re: Child packages [nn,pedo,incest,cons] Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <1994Oct4.090807@di.epfl.ch> <1994Oct17.091621@di.epfl.ch> Date: Mon, 17 Oct 1994 21:54:07 GMT Date: 1994-10-17T21:54:07+00:00 List-Id: In article , Robert I. Eachus 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.)