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-29 10:33:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!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: <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 29 Jul 2003 13:18:29 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1059499102 198.96.223.163 (Tue, 29 Jul 2003 13:18:22 EDT) NNTP-Posting-Date: Tue, 29 Jul 2003 13:18:22 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:40957 Date: 2003-07-29T13:18:29-04:00 List-Id: 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. Many of these issues are tough to decide up front, particularly if these are libraries for users to use. However, when I used C++, I tended to leave protected out (disallowing access to internal members), until I had a good reason to do otherwise. While it has been a while since I looked at M$ code, I believe they use it (or not, depending upon its intended use) displaying some decision making there. > What I would like to have > > 1. multiple parents; This could be useful, no doubt. But it also introduces new issues but I suppose I would reluctantly endorse MI if pressed to make a choice. > 2. an ability to choose which members are public and which are not > (presently one needs a two-stage deriving); Yes. > 3. an ability to have public read-only members with full access in the > private part; Yes. Even C++ lacks this. However, one could argue that you should always provide an "interface" to these, but from a practical level, I find this a big pain. > 4. a finer control over overridings (a vast theme). Certainly an area of discussion. The practical question is whether things need to be done about the present scheme of things, or not. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg