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,23cf9f1e93744eed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-30 14:15:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!wn14feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 30 Jul 2003 17:00:00 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059598792 198.96.223.163 (Wed, 30 Jul 2003 16:59:52 EDT) NNTP-Posting-Date: Wed, 30 Jul 2003 16:59:52 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:41045 Date: 2003-07-30T17:00:00-04:00 List-Id: Dmitry A. Kazakov wrote: > On Tue, 29 Jul 2003 13:18:29 -0400, "Warren W. Gay VE3WWG" > wrote: >>Dmitry A. Kazakov wrote: >> >>>On Sun, 27 Jul 2003 18:02:08 -0400, "Warren W. Gay VE3WWG" >>> wrote: >>> >>>>Robert I. Eachus" wrote in message news:3F22F9E9.3040307@attbi.com... >>>> >>>>>Warren W. Gay VE3WWG wrote: >>>>> >>>>>>[As a side note, I sometimes wonder if an enhancement to the Ada0Y >>>>>>language might be to be able to specify a limited visibility of a >>>>>>parent package's object's internals (a la not "protected" type in >>>>>>C++). A protected class in C++ allows derived code to mess with the >>>>>>internals, whereas normally the parent object's elements are a >>>>>>black box. Use of limited visibility helps to reduce code coupling.] >>>>> >>>>>Actually, that is what a private child package is for. It allows you to >>>>>move all of the "useful" internals out of a package body to a place >>>>>where the body and all the child packages can access them. >>>> >>>>Actually, what I had in mind was the object visibility here (not >>>>package visibility). When deriving from existing tagged records, there >>>>is no way to limit the visibility of the parent object's members (a >>>>la "protected" in C++/Java). A derived object can freely mess with any >>>>tagged record's members, as it sees fit. Information hiding >>>>and reduced coupling practices suggests that this is not the safest >>>>route (best to use the existing parent object methods to mess with >>>>the "parent members"). >>> >>>I do not know whether there is a statistics regarding use protected >>>vs. private, but I think that most C++ programmers just stick to >>>public vs. not. Burden of decision is too heavy for many. ... > Comparing C++ with Ada, we could say that Ada's "private" is rather > C++'s "protected". Then Ada has, and C++ lacks, an ability to define > subroutines with full access to members in the package body, without > any specification changing. The problem occurs in the private child package (IMO) because you want to derive new objects from parent tagged records. The danger that develops is that the child package's body code may monkey with things in the parent object that you don't want it to (this is lack of information hiding). However, you can fix the object visibility by making it a non child package (just another package using the first). However, the problem then becomes that you lose access to other types and definitions that are in the other package's private part. So in my mind, there still exists a short-coming OO wise in the visibility rules for objects: it needs a way to mark parts of a tagged object as "off limits" for the child package, which always enjoys full visibility of the parent package's tagged record (object). > Such subroutines could be viewed as an > equivalent to C++'s "private methods". What Ada does not have are > private data members in C++ sense. So we have: > > protected in C++ <--> private in Ada > private method <--> a subroutine in the body [a FAT plus to Ada ] > private member <--> missing [a minus] I think you need to add a dimension to this "chart", because there are multiple (at least 2) views: 1. simple client view 2. a _normal_ child package view (a _private_ child's view is the same I think, but if not, this is a 3rd). The problem I am trying to address, is #2. The child package sees all, even when you don't want it to. > From my point of view, Ada's model is clearer and more consitent with > separate compilation / development model. Private, in C++ sense, > things should actually never appear in the specification. Well, one could argue that the private parts of a specification should never be seen by clients (particularly for libraries where body code is not provided). However, there are obviously practical compiler reasons for including those things ;-) One other raod a compiled language like Ada could have taken, is to compile an intermediate file for those parts of a spec that are required by the compiler, but should not be seen by the client. But this has other practical problems, I suspect. > I remember, Robert Duff, proposed a way to hide everything really > *private* in the bodies. This would be IMO a right thing. A child package often needs types and other constants from the parent package, but "wants" the safety of not dabbling with the parent object's internals. Warren. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg