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,FREEMAIL_FROM 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!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail From: danmcleran@hotmail.com Newsgroups: comp.lang.ada Subject: Re: Possible Ada deficiency? Date: 10 Jan 2005 14:29:39 -0800 Organization: http://groups.google.com Message-ID: <1105396179.381458.84950@f14g2000cwb.googlegroups.com> References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1105290947.422412.195950@c13g2000cwb.googlegroups.com> <1105327217.641306.80180@c13g2000cwb.googlegroups.com> NNTP-Posting-Host: 192.55.20.36 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1105396185 12468 127.0.0.1 (10 Jan 2005 22:29:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 10 Jan 2005 22:29:45 +0000 (UTC) In-Reply-To: User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=192.55.20.36; posting-account=LSix6gsAAACmBFWMCbh6syCaua0lawvj Xref: g2news1.google.com comp.lang.ada:7628 Date: 2005-01-10T14:29:39-08:00 List-Id: >But if you have a package X.Y that does not want to >access private-X stuff, then why do you want it to be a child in the >first place? That's not the point. If I am writing a package, I want to be able to hide certain stuff from all future child packages. I may be the one writing the child package, I may not be. The way I'm thinking in this discussion is I am not the one writing the child package. So, that being said, I want to have a way to hide certain implementation details from all future child packages, written by whomever. The private area would remain as-is, with child packages having full visibility there. The 'concealed' area is an area that I do not want child packages messing with. I would only put things, (mostly type(s)), in the 'concealed' area that I want fully encapsulated from the outside world, including child packages. This would force a child package to use the public or private interface of the parent package for types declared 'concealed'. >In my suggested solution, X could declare "I have no children", and then >Y would have to be *not* a child of X. I would like a variation of this idea. If one could specify that a package could not have child packages, then the compiler could prevent someone from even compiling X.Y. It would be nice to prevent future developers from writing child packages if you don't want them to. >But obviously it doesn't *need* >to be a child of X, since it does not access private-X stuff. That's not what I'm saying. I would not propose re-defining private. I would propose the addition of 'concealed'.