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-27 15:02:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!newsfeed.news2me.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> Subject: Re: Need advice re package organization. X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Sun, 27 Jul 2003 18:02:08 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059343660 24.150.168.167 (Sun, 27 Jul 2003 18:07:40 EDT) NNTP-Posting-Date: Sun, 27 Jul 2003 18:07:40 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40875 Date: 2003-07-27T18:02:08-04:00 List-Id: 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"). -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg