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,b1f194b75ae020e4 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-29 18:15:17 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!hudson.lm.com!godot.cc.duq.edu!newsfeed.pitt.edu!uunet!tandem!telesoft!kst From: kst@thomsoft.com (Keith Thompson) Subject: Re: children 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: <3kv64j$1fhh@info4.rus.uni-stuttgart.de> <3l3kp9$rgv@gnat.cs.nyu.edu> Date: Thu, 30 Mar 1995 02:15:17 GMT Date: 1995-03-30T02:15:17+00:00 List-Id: In <3l3kp9$rgv@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: > We can't do *everything* a CM does in Ada. The question is always how far > to go. There is therefore no principle involved here, just a matter of > practicalities and pragmatic convenience. After all if you have no CM at > all the discussion is silly, since you can always edit the source and > remove the pragma anyway. It seems to me that a lot of the arguments against adding a language feature to restrict child units could as easily be made against enforcing the privacy of private parts/types at all. Consider something like this: package Stacks is type Stack is private; procedure Push(...); procedure Pop(...); ... private Max_Length: constant := ...; type Stack is record TOS: Natural := 0; Elements: array(1 .. Max_Length) of ...; end record; end Stacks; with Stacks; procedure Client is My_Stack: Stacks.Stack; begin ... end Client; Why, one might argue, should the language prevent Client from accessing My_Stack.TOS and My_Stack.Elements directly when a sufficiently clever CM system could enforce the restriction? Yes, this is an exaggeration of the issues, but I think it illustrates the point. I think the reason for all the brouhaha is that Ada 95, by adding child units, has slightly weakened the privacy of private parts. An Ada 83 private part is theoretically inviolate (barring Unchecked_Conversion or modification of the source and recompilation of whatever depends on it, of course). An Ada 95 private part isn't, and there's no convenient way to enforce the same level of privacy provided by Ada 83. Counterarguments, of course, are that the privacy isn't violated unless you "with" the child unit, and you can get back the same level of privacy by some minor contortions with nested private parts; that's why I said it's *slightly* weakened. Mind you, I *like* child units, and I'm glad that Ada 95 has them. I'm just suggesting that a little bit of theoretical security has been lost relative to Ada 83; it's not surprising that a lot of people are uncomfortable with that. -- 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'.