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-Thread: 103376,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Fri, 07 Jan 2005 15:30:54 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1104544963.930877.75170@c13g2000cwb.googlegroups.com> <1104595073.731663.180100@c13g2000cwb.googlegroups.com> Subject: Re: Possible Ada deficiency? Date: Fri, 7 Jan 2005 15:32:31 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-yNyGWgYQ0wwVFSHP6Vi86zH5vv2XO+c7UwnIHR0yiulSwOqpRrHsHHG8kKeuxcjBsa5AUNDonNDpBS6!PfV+ta1/Ks7pGs/KRmP6MNvqFHNjeIzjpQmVaIB+5cSkznKVDktzgCLvxeEUBiHRs5k/SDCzmYSi X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.22 Xref: g2news1.google.com comp.lang.ada:7550 Date: 2005-01-07T15:32:31-06:00 List-Id: "Nick Roberts" wrote in message news:gemini.i9yj3c0051not02as.nick.roberts@acm.org... > "Randy Brukardt" wrote: > > > The purpose of a child package is to extend its parent, often in ways not > > forseen by the parent's author. You're trying to prevent that purpose. If > > you don't want access to the private information, then don't write > > children. You have to at some point trust programmers to do something > > sensible; it's not the least bit hard to use 'Address or > > Unchecked_Conversion to access the private information of a package, no > > matter where you hide it. > > I think you're missing the point a little, Randy. > > Suppose there are some things in the private part of a package that you do > want private children of the package to be able to see (and modify), and > some other things in the private part that you do not want even private > children to be able to see (or modify). > > In this case, it would seem it may be useful to have language construct that > allows this intention to be clearly stated, and enforced by the compiler. There is, it's called the "body". :-) > If the intention later turns out to be an obstacle, the construct can be > changed or removed. But if the intention is /accidentally/ violated, it > could be very useful for the compiler to detect it and flag it up. > > I suppose the problem is, such a construct would imply the need for a new > kind of private child -- perhaps a 'private private' child ;-) -- which > could access the secret stuff. And then one might have ultra-secret stuff, > and then ultra-secret children, and so on. > > So possibly the argument against is that it would be overkill. Right. When the ARG considered adding an extra part to package specifications to support mutually dependent packages (which eventually was handled with limited with), there were two major concerns: 1) the interactions of the visibility rules for private parts with other rules of the language are already very complex (and hard to implement). We'd be nuts to double those interactions with a new kind of package part. 2) How would the user be able to decide what part to put things in? Imagine the world if all of these proposals had been accepted: package would have 5 parts! (abstract, visible, private, concealed, body). The way to solve this problem is to figure out how to put more stuff into the body, not inventing new kinds of parts. It has been claimed (correctly, IMHO) that the private part originally was a hack to allow compilers to be written more easily. Ada 95 gave it a second use (exporting stuff within the subsystem to child units), and it is the conflict between the hack and the legitimate use that is causing the problem. So the real solution is to get rid of the requirement for the hack. But there currently isn't the will to do that - maybe next time. Randy.