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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,efe03f20164a417b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-24 13:33:14 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!howland.reston.ans.net!swrinde!emory!news-feed-1.peachnet.edu!paperboy.wellfleet.com!noc.near.net!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: An observation of Ada (may offend) Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. X-Newsreader: TIN [version 1.1 PL8] References: <3ku7us$117l@info4.rus.uni-stuttgart.de> Date: Fri, 24 Mar 1995 21:33:14 GMT Date: 1995-03-24T21:33:14+00:00 List-Id: Peter Hermann (ucaa2385@alpha1.csv.ica.uni-stuttgart.de) wrote: [Various proposals relating to limiting the use of child units.] : I would not recommend that whole direction because : one of the strengths of the child feature is exactly the fact, : that the parent need not be touched further on. : For Ada200X, the abs private part may be more convenient (if any) : but, imho, this overburdening of the language is superfluous. Here, here. Child units are a namespace structuring mechanism. A fundamental characteristic of this structuring mechanism is that the spec of the parent does not depend on the children. Furthermore, if a child unit is not mentioned in some "with" clause, it is as though it doesn't exist at all, and will not be included in the program. Hence, adding an "unwanted" child has no effect on any program that does not explicitly mention that child in some with clause. Adding a child is simply extending the interface of the abstraction represented by the tree of library units. Without child units, this is done by entering a new version of a package into a library after adding more subprograms to the package. With child units, you can accomplish the same thing by entering the new child into the library. In both cases, if you want to control access or update to the library, then you need to use the O/S or the Ada compiler to do it. Access control is not a language issue, it is a tool or O/S issue. Note that using child units is actually *safer* than the "old" approach where one simply edited the package that represented the entire abstraction, since as mentioned above, the only clients that can possibly be affected are those that explicitly add a "with" clause for the new child. With the "old" approach where someone goes in and adds or changes stuff in the original package, it is much less obvious which clients might be affected. So a pragma that lists the names of child units is the moral equivalent to a comment at the top of a package that lists the names of all of the subprograms in the package. It proves nothing, and simply creates busy work during maintenance, since it must be updated every time you want to add a new child (and don't tell me somehow that your tools can prevent me from entering a new version for the parent package, but they can't prevent me from adding a new child). Some kinds of redundancy are useful, but these kinds of redundant lists are a waste of energy. If you want a list of the children, get a list from the program library manager (a.k.a "list directory" on GNAT). Similarly, if you want a list of the subprograms in a package, use "grep." If you want to lock out unauthorized additions or changes to *your* program library, use "chmod" (or whatever). This whole thing reminds me of attempts to add silly amendments to the US constitution ;-). : -- : Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de : Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen : Team Ada: "C'mon people let the world begin" (Paul McCartney) -Tucker Taft stt@inmet.com Intermetrics, Inc.