Re: Q's: nested packages / visibilty

[matthew_heaney@acm.org (Matthew Heaney)]

In article <9v6hGdgMLuwN-pn2-VFf4e0fMp6MD@dt182n2f.tampabay.rr.com>,
cpallen@nospam.com (Craig Allen) wrote:

>I have questions concerning nested packages.
>
>1st question:
>
>I want to take a package and divide it up into several pieces.  As I 
>understand it, there are 2 ways to do this.
>
>   1 way places the specifacation (declaration?) for the nested 
>package inside the specification for the parent package.  This causes 
>the contents of the sub-package to be available to any unit 
>referencing the parent package.

Correct.

>   The other places the spec for the nested package inside the 
>declarative part of the body of the parent package.  In this way, only
>the parent is allowed to use the procedures in the sub-package.

Correct.

>What I'm wondering is this:  Is there a way to have a sub-package that
>has some of its procedures visible only to the parent package, and 
>others that are visible to external units?  (Where does the spec go?)

Not really.  

In general, I would avoid nesting packages anyway.  Just declare the things
you'd declare in the nested package right in the (spec of the)  enclosing
package.  It's a pain for clients to have to refer to items in a nested
package, and it tends to create large packages.

>I thought about using 'private' to do this, but that seems to apply to
>data types.  Could it also apply to procedures?

You can declare procedures in the private part of the spec, but it doesn't
buy you very much.  Just declare them in the package body.

>2nd related question:
>
>When I make a sub-package that will be used only by the parent 
>package, The sub package body & spec both appear in the declarative 
>part of the parent package.  Now I see I can use 'separate' to move 
>the body to another (compilation unit) - this cleans the code up quite
>a bit and is exactly what I'm looking for.

Yes.

>Can I not also do 
>something about the specification for this sub-package?  Right now it 
>is still sitting in the parent package.  I would like to move it to 
>it's own separate file as well, and somehow just include it in the 
>parent, but I don't think you can put a 'with' there, and if I try to 
>put  the with for this file at the top of the parent package, it 
>doesn't work.  Isn't there a way for me to clean this up further by 
>moving this (possibly lengthy) package specification elsewhere?

Why not just make it its own library level unit?

In general, you want to submit as little program text to the compiler as
possible.  If you have a "possibly lengthy" package that's nested, then
move it out of there, so it's not nested anymore.

About the only reason to create a nested package is to give the nested
package visibility to the private part of the enclosing package.  The
problem is that it creates humongous packages, which creates compilation
headaches.

In Ada 83, if you want to share some private information, move that
information out into an (unencapsulated) different package, that is with'd
by the two existing packages.  ie, instead of

package P is

   package Q is
      ...
   end Q;
...
private

   <private details of P>

end P;

do this:

package P_Private is

   <private details of P>

end P_Private;

with P_Private;
package P is
...
private
   <refer to "private" stuff in P_Private>
end P;

with P_Private;
package Q is
...
private
   <refer to "private" stuff in P_Private>
end Q;


Of course, P_Private is unencapsulated, but this is harmless, as long as
everyone agrees not to with P_Private.  That package is for the exclusive
use by P and Q.   No, there is no way to enforce this in Ada83, but that's
why Ada95 was invented.