Q's: nested packages / visibilty

Q's: nested packages / visibilty

[Craig Allen]

Hello again.

First of all, I would like to preface my question with the fact that 
I'm using Ada83, so please tailor any responses accordingly.

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.

   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.

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

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

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


Thanks in advance for any help.
-Craig

Re: Q's: nested packages / visibilty

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

Re: Q's: nested packages / visibilty

[Ed Falis]

I didn't see the original full post, but it sounds like what Craig is 
after is a private child package:

package Parent is

-- generally visible stuff
private
-- as needed
end Parent.

private package Parent.Restricted is
-- stuff only for use by the parent or other children for 
implementation
private
-- whatever
end Parent.Restricted;

with Parent.Restricted;
package body Parent is
-- implementation
end Parent;

Of course, if he said he was using Ada 83, all bets are off on 
this approach.
- Ed