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!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail From: "Tucker" Newsgroups: comp.lang.ada Subject: Re: Possible Ada deficiency? Date: 16 Jan 2005 20:40:16 -0800 Organization: http://groups.google.com Message-ID: <1105936816.827842.186420@f14g2000cwb.googlegroups.com> References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> NNTP-Posting-Host: 146.115.115.45 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1105936820 23273 127.0.0.1 (17 Jan 2005 04:40:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 17 Jan 2005 04:40:20 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=146.115.115.45; posting-account=5nI3tQwAAAAG-bRSBGaGphNiAvs9Tj2U Xref: g2news1.google.com comp.lang.ada:7857 Date: 2005-01-16T20:40:16-08:00 List-Id: danmcleran@hotmail.com wrote: > I would like to know if anyone else thinks that the inability to hide > private information from child packages is a deficiency in Ada95. I am > discussing ways to do this on another thread, (See Private area and > child packages), but it seems wrong that one has to go through a bunch > of machinations to do something like this. Wouldn't a language > construct for this be advantageous? We considered this during the Ada 95 design process. Our conclusion was that C++ public/protected/private was analogous to Ada's "visible part of pkg spec"/ "private part of pkg spec"/"body of pkg". C++ doesn't really have the equivalent of a "body." If you want to add a new function that is only usable within a given class, you generally still have to declare it in the ".h" (unless you play games with "friends"), which is a royal pain IMHO. If you really need to declare something in a package spec, but you don't want it visible to children, one solution is to declare it in a nested package. The private part of a nested package is not visible to children. One consideration, however, is that trying to hide something from all possible future children may be overengineering. Some C++ coding styles encourage use of "protected" rather than "private," since it is hard to foresee all of the kinds of extensions that might be necessary in the future. However, in C++, "protected" is troublesome during maintenance, since *all* derivatives of a type can see its protected components, no matter where the type is declared. And the type hierarchy below a type may be very large, and spread all over the place. On the other hand, Ada's approach to "partial" privacy forces any package which needs visibility to be given a name which essentially makes it part of the "subsystem" where the data is defined. Although there is nothing preventing someone from creating their own child of someone else's subsystem, when they do that, they generally accept the fact that they may need to be prepared to do some work next time a new revision of the subsystem is released. On the other hand, in C++, you are generally encouraged to get the advantages of reuse by creating lots of derivatives of a type, and you are probably less likely to think you are signing up for a potential maintenance burden when a new version of the base type is released. I agree it is a subtle distinction, but in my experience, it creates the right kind of subtle incentive. When someone creates a child of someone else's subsystem, they do so to export a bit more information, rather than dumping all of their own logic into the child. So the net effect is that the amount of code that has visibility is smaller, and so the ability to accommodate a change to the parent package is better. > > In C++ and Java, no private data can be seen by child classes. I think > that Ada would benefit from extending its information hiding > capabilities by allowing a package writer to conceal type information > from child packages. > > What if Ada had a keyword, I've chosen 'concealed' for the sake of > discussion, to indicate that the implementation of a type was not > visible to the outside world (including child packages)... Wrapping the type in a nested package can be used to accomplish approximately what you need. -Tucker Taft