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 21:15:42 PST Path: bga.com!news.sprintlink.net!pipex!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Child packages Date: 19 Oct 1994 14:54:51 -0400 Organization: Courant Institute of Mathematical Sciences Message-ID: <383q1r$mji@gnat.cs.nyu.edu> References: <1994Oct4.090807@di.epfl.ch> <37kanl$jfd@u.cc.utah.edu> <1994Oct18.103131@di.epfl.ch> <3816h5$n3g@schonberg.cs.nyu.edu> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-10-19T14:54:51-04:00 List-Id: I think it is Robert Eachus who is being misleading and alarmist here. First of all, it is perfectly possible to write packages now which break the private type interface, by using unchecked conversion, and do all sorts of horrible things. Why is this not a disaster? Because you know from the package (with unchecked conversion) that is is potentially a problem, and you know that you DON'T have anything to worry about if the package is not included in a program. Exactly the same holds true for child packages. I really think all this worrying about them is bogus. In fact you are much better off with a child package than you are if someone simply mucks directly with the source of a supposedly secure package. OK, you say, we have these wonderful configuration managers that prevent that sort of thing -- fine have these wonderful cm's also restrict what people can do with child packages. The bottom line is that child packages add no fundamental functionality. There is nothing that you can do with them that you cannot do without them, including busting abstractions. What they allow is much more convenient package of a program into components, and indeed some of these components may be mucking with abstractions, possibly in a naughty way, but you are still ahead. Consider the following two possibilities: someone has mucked with the source of a critical package and broken the abstraction. All programs that with this package are bust. someone has added a child package to a critical package, and broken the abstraction. Only programs that with the child package are bust. It seems clear that situation two is a huge improvement over the "ada 83" way of breaking abstractions represented by situation one. Of course you can still illegally muck with packages you shouldn't touch in Ada 9X, but given the possibility of child packages, it is now practical to really "lock the door" and forbid any mucking with critical packages and to forbid the use of unchecked conversions. This kind of draconian action could be done in Ada 83, but then there is no way out for an isolated special program to get its hands on the private data. Ada 9X allows such a method, if you care to permit it.