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,d60e0492375aa57a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-31 05:06:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!intgwlon.nntp.telstra.net!news.telstra.net!news-server.bigpond.net.au!not-for-mail From: Dale Stanbrough Newsgroups: comp.lang.ada Subject: Re: Visibility of private packages?? References: <3d47a99e.4548109@news.demon.co.uk> User-Agent: MT-NewsWatcher/3.2 (PPC Mac OS X) Message-ID: Date: Wed, 31 Jul 2002 12:06:39 GMT NNTP-Posting-Host: 144.132.42.132 X-Complaints-To: news@bigpond.net.au X-Trace: news-server.bigpond.net.au 1028117199 144.132.42.132 (Wed, 31 Jul 2002 22:06:39 EST) NNTP-Posting-Date: Wed, 31 Jul 2002 22:06:39 EST Organization: BigPond Internet Services (http://www.bigpond.net.au) Xref: archiver1.google.com comp.lang.ada:27520 Date: 2002-07-31T12:06:39+00:00 List-Id: Peter.Coventry@gdcanada.com wrote: > > >I am trying to get my head around the visibility rules applicable to private > >packages. > > > >If I have the following package hierarchy: > > > > A > > / \ > > A.B1 A.B2 > > / > > A.B1.C1 > > > >A.B1 contains the interface that I wish to export to clients (i.e a type > >plus routines for client manipulation). > >A.B1.C1 contains additional routines for the type not meant for client use. > >A.B2 contains some inner workings, that need to use the additional routines > >in A.B1.C1. > > > >I want to make A.B1.C1 a private package to stop it from being misused by > >clients, however the compiler disallows it, citing RM 10.1.2(8): > > > >" If a with_clause of a given compilation_unit mentions a private child of > >some library unit, then the given compilation_unit shall be either the > >declaration of a private descendant of that library unit or the body or > >subunit of a (public or private) descendant of that library unit." > > > >Does this mean that if A.B1.C1 is private, it can only be withed by the > >bodies of A.B1 and other descendants of A.B1, and specs of private packages > >of descendants of A.B1? Yes, that's correct. I think this is a case where the designers got it wrong. The current rules prevent "compilation coupling", that is any change to a private package will never result in the need to recompile a package outside of the hierachy. A laudible aim, but too restrictive IMHO. It would have been better to simply restrict the use of types defined in a private spec to either the private part of a package spec, or the package body. This would allow you to, for example, complete a private type declaration with a type derived from a private package, or a structure with a private component. E.g. private package a.b is type hidden is end a.b; with a.b; package a.c is type not_hidden is private; private type not_hidden is new a.b.hidden; end; The change could be made, and it would not be incompatable with existing programs. Dale