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 01:37:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!news-feed1.de1.concert.net!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. Date: Wed, 30 Jul 2003 10:42:39 +0200 Message-ID: References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1059554277 22926592 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40990 Date: 2003-07-30T10:42:39+02:00 List-Id: 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. > >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. 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. 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] >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. I remember, Robert Duff, proposed a way to hide everything really *private* in the bodies. This would be IMO a right thing. >> 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. Actually I meant multiple package parents. But, yes, I wish MI as well. >> 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. That's the crucial point. Any public declaration is (or has to be) an interface. Moreover, I wished a full blown ADT in Ada. This would mean that if you declare type A is record X : Something end record; in the public part, it should to be treated as an interface, not as a specification of a representation. So in the private part you could say that A is actually an access type and provide Get/Set to deal with X. >> 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. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de