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-28 09:23:06 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!stern.fokus.gmd.de!ceres.fokus.gmd.de!zib-berlin.de!news.mathworks.com!udel!gatech!swrinde!cs.utexas.edu!math.ohio-state.edu!usc!crash!telesoft!kst From: kst@thomsoft.com (Keith Thompson) Subject: Re: Child packages X-Nntp-Posting-Host: pulsar Message-ID: Originator: kst@pulsar Sender: news@thomsoft.com (USENET News Admin @flash) Organization: Thomson Software Products, San Diego, CA, USA References: <3kbkm1$41o@miranda.gmrc.gecm.com> <3kcflv$164a@watnews1.watson.ibm.com> <3ku7us$117l@info4.rus.uni-stuttgart.de> <1995Mar27.115304@di.epfl.ch> Date: Tue, 28 Mar 1995 01:11:12 GMT Date: 1995-03-28T01:11:12+00:00 List-Id: In <1995Mar27.115304@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes: > I don't see how something like who can add a child package is fundamentally > any different that who can modify a package. In my opinion a pragma > to deal with this situation would do more harm than good. For a set of compilation units provided by a commercial vendor, the full specification and body sources may not be available, making modification difficult or impossible. Adding a child unit is relatively easy. (Some would argue that all the sources should always be made available, but I don't think that assumption should be built into the language; realistically, sources *won't* always be available.) One advantage of such a pragma is that it gives users an ability that currently only implementations have. I think this has always been a design goal of Ada. (For example, unlike their equivalents in many other languages, Character is an ordinary enumeration type and Text_IO is an ordinary library package; users can write their own replacements for them if desired.) RM95-A(4) says The implementation may restrict the replacement of language-defined compilation units. The implementation may restrict children of language-defined library units (other than Standard). In a small way, this gives the language-defined units a special status. An implementer of a set of non-language-defined units can have the same reasons to impose such restrictions that an implementer of the language-defined units might have. On the other hand, the only real extra power a child unit gives you is visibility to the parent's private part. You can restrict this by hiding implementation details within a *nested* private part (this is based on something Tucker Taft briefly mentioned a while ago). package Black_Box is type Hidden is private; private package Inner_Black_Box is type Inner_Hidden is private; private type Inner_Hidden is (Why_Are_You_Looking_At_Me); end Inner_Black_Box; type Hidden is new Inner_Black_Box.Inner_Hidden; end Black_Box; Now even a private child of package Black_Box can't access the full declaration of type Hidden. Since child units can only be declared at the library level, you can't declare a child of Inner_Black_Box, so its private part is truly private. Admittedly, this doesn't let you selectively export private types to some units but not to others. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com (kst@alsys.com still works) TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.