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-28 01:38:41 PST Path: archiver1.google.com!news1.google.com!sn-xit-03!sn-xit-01!sn-xit-08!supernews.com!freenix!proxad.net!newsfeed.stueberl.de!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: Mon, 28 Jul 2003 10:38:44 +0200 Message-ID: <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.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 1059381251 21060632 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:40894 Date: 2003-07-28T10:38:44+02:00 List-Id: 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. What I would like to have 1. multiple parents; 2. an ability to choose which members are public and which are not (presently one needs a two-stage deriving); 3. an ability to have public read-only members with full access in the private part; 4. a finer control over overridings (a vast theme). --- Regards, Dmitry Kazakov www.dmitry-kazakov.de