Visibility of private packages??

Visibility of private packages??

[Peter Coventry]

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?

If this is the case, how could I structure things to give the desired
effect?

Thanks.

Re: Visibility of private packages??

[John McCabe]

On Tue, 30 Jul 2002 15:23:40 -0600, "Peter Coventry"
<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?
>
>If this is the case, how could I structure things to give the desired
>effect?

As far as I remember, "Ada As A Second Language" by Norman Cohen has
some reasonable stuff on private child packages so it might be worth
looking there.

If the type you are referring to is tagged, would it help to declare
the A.B1.C1 facilities as dispatching operations in the private part
of A?

Re: Visibility of private packages??

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]


"Peter Coventry" <Peter.Coventry@gdcanada.com> a �crit dans le message news: DtD19.636$C8.2739@nnrp1.uunet.ca...
> 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

> If this is the case, how could I structure things to give the desired
> effect?
Make it a private child of A, ie :
private Package A.B3 is ...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Visibility of private packages??

[Dale Stanbrough]

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 <something>
   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

Re: Visibility of private packages??

[Mark Doherty]

> 
> 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

> 
> If this is the case, how could I structure things to give the desired
> effect?

A private child is never visible outside the tree routed at its
parent. And within that tree it is not visable to the specifications
of public siblings!

Try looking in 'programming in ada95 2nd edition' by john barnes page
247. it has a nice diagram.


Mark

Re: Visibility of private packages??

[Robert A Duff]

Dale Stanbrough <dstanbro@bigpond.net.au> writes:

> 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.

Isn't the ARG considering relaxing this rule?

- Bob

Re: Visibility of private packages??

[Anh_Vo]

Just change private package A.B1.C1 to private package A.B3. A.B2 body
can with A.B3 package. Thus, the desired effect is achieved.

"Peter Coventry" <Peter.Coventry@gdcanada.com> wrote in message news:<DtD19.636$C8.2739@nnrp1.uunet.ca>...
> ...
> 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?
> 
> If this is the case, how could I structure things to give the desired
> effect?
> 
> Thanks.

Re: Visibility of private packages??

[Randy Brukardt]

Robert A Duff wrote in message ...
>Dale Stanbrough <dstanbro@bigpond.net.au> writes:
>
>> 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.
>
>Isn't the ARG considering relaxing this rule?

Yes, AI-262, "private with". Already approved by the ARG. The example
would be written in Ada 0Y as:

   private package a.b is
      type hidden is <something>
   end a.b;

   private with a.b;
   package a.c is
      type not_hidden is private;
   private
      type not_hidden is new a.b.hidden;
   end;

              Randy Brukardt

Re: Visibility of private packages??

[Dale Stanbrough]

Randy Brukardt wrote:

> Yes, AI-262, "private with". Already approved by the ARG. The example
> would be written in Ada 0Y as:
> 
>    private package a.b is
>       type hidden is <something>
>    end a.b;
> 
>    private with a.b;
>    package a.c is
>       type not_hidden is private;
>    private
>       type not_hidden is new a.b.hidden;
>    end;
> 
>               Randy Brukardt

Excellent! Time to drag out some old programs.

Does anyone know if any compiler vendors have implemented this
yet? (and more significantly for me, has Gnat implemented it?). 
I tried it out on the Mac port (which calls itself GNAT 5.00w)
but it objected.

Dale

Re: Visibility of private packages??

[Robert Dewar]

Dale Stanbrough <dstanbro@bigpond.net.au> wrote in message news:<dstanbro-E13D57.19534014082002@news-server.bigpond.net.au>...
> has Gnat implemented it?). 
> I tried it out on the Mac port (which calls itself GNAT 
> 5.00w)
> but it objected.
> 

We have no current plans to implement this extension (it is
not something for which we have had any demand).

Robert Dewar
Ada Core Technologies

Re: Visibility of private packages??

[Randy Brukardt]

Dale Stanbrough wrote in message ...
>Randy Brukardt wrote:
>
>> Yes, AI-262, "private with". Already approved by the ARG. The example
>> would be written in Ada 0Y as:

> ...
>
>Excellent! Time to drag out some old programs.
>
>Does anyone know if any compiler vendors have implemented this
>yet? (and more significantly for me, has Gnat implemented it?).
>I tried it out on the Mac port (which calls itself GNAT 5.00w)
>but it objected.

So far as I'm aware, no vendors have implemented this yet. The ARG just
approved it at the last meeting, so I'm not surprised about that. The
only "new" thing that I know has been implemented by any compiler (as
opposed to things that are present in many compilers already, like
Unchecked_Union) is type stubs. But I don't know if those
implementations will be made available to customers any time soon.

              Randy.