Giving a package specification access to the private types of another package

Giving a package specification access to the private types of another package

[Steven Murdoch]

I would like to use a package A from within another package B, however
the specification of A uses types that are declared in the private part
of package B. I could solve this by inserting the contents of the package
A in B, but is there another way with which I can keep the two files
separate (so as to improve clarity).

Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[Preben Randhol]

Steven Murdoch wrote:
> I would like to use a package A from within another package B, however
> the specification of A uses types that are declared in the private part
> of package B. I could solve this by inserting the contents of the package
> A in B, but is there another way with which I can keep the two files
> separate (so as to improve clarity).

make A a child package of B

B.A

-- 
Preben Randhol ------------------------ http://www.pvv.org/~randhol/ --
                          �1984 is soon coming to a computer near you.�

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <slrnavbse4.5r4.randhol+news@kiuk0152.chembio.ntnu.no>,
 Preben Randhol <randhol+news@pvv.org> writes:
>make A a child package of B

It already is, but I have the same problem. I think if A is a child of
B then the body of A can see the body of B, but the public specification of
A cannot see the body of B (which is what I need).

One of the functions in A takes in a parameter of type C, where C
is declared in the private part of B. This function is not used
anywhere other than the body of B.

Thank you,
Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[Grein, Christoph]

> It already is, but I have the same problem. I think if A is a child of
> B then the body of A can see the body of B, but the public specification of

No, that's wrong. No unit can ever see inside the body of another unit. The body 
is hidden from all visibility.

> A cannot see the body of B (which is what I need).

A child'body of a unit can see in the private part of its parent.
A private child's spec can see in the private part of its parent.
A child's private part can see in the private part of its parent.

Privateness can be nested. You can have private children of public parents, but 
also public children of private parents and private children of private parents. 


        package A     is ... end A;
private package A.B   is ... end A.B;
        package A.B.C is ... end A.B.C;  -- public within A.B
private package A.B.D is ... end A.B.D;  -- private within A.B

A.B.C'Spec does not see A.B.D (because the latter is private).
A.B.C'Body does see A.B.D'Spec.

with A;      -- legal
with A.B;    -- illegal
with A.B.C;  -- illegal
package X is ...

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <slrnavbse4.5r4.randhol+news@kiuk0152.chembio.ntnu.no>,
 Preben Randhol <randhol+news@pvv.org> writes:
>make A a child package of B
>
>B.A

Here is an example of the code I currently have. The error I get is:
""Private_Type" is not visible" for b-a.ads

--b.ads
package B is
   procedure Proc_B;
private
    type Private_Type is new Integer;
end B;

--b.adb
with B.A;
package body B is
   procedure Proc_B is
      Temp: Private_Type;
   begin
      A.Foobar(Temp);
   end;
end B;

--b-a.ads
package B.A is
   -- "Private_Type" is not visible
   -- non-visible (private) declaration at b.ads:4
   procedure Foobar(Temp: in Private_Type);
end B.A;

--b-a.adb
package body B.A is
   procedure Foobar(Temp: in Private_Type) is
   begin
      null;
   end;
end B.A;

Thank you,
Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[James S. Rogers]

"Steven Murdoch" <news01+Steven.Murdoch@cl.cam.ac.uk> wrote in message
news:at4sfs$m2r$2@pegasus.csx.cam.ac.uk...
> In article <slrnavbse4.5r4.randhol+news@kiuk0152.chembio.ntnu.no>,
>  Preben Randhol <randhol+news@pvv.org> writes:
> >make A a child package of B
>
> It already is, but I have the same problem. I think if A is a child of
> B then the body of A can see the body of B, but the public specification
of
> A cannot see the body of B (which is what I need).
>
> One of the functions in A takes in a parameter of type C, where C
> is declared in the private part of B. This function is not used
> anywhere other than the body of B.

You clearly have a poor organization. Try to think a bit more about
modularity when designing packages. Either A and B should be
merged into a single package, or pieces of A and B should be
moved from one package to the other.

Jim Rogers

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <mailman.1039530902.542.comp.lang.ada@ada.eu.org>,
 "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
>A private child's spec can see in the private part of its parent.

This was the case I needed, making the spec private fixed my problem.

Thank you,
Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <M_mJ9.53337$hK4.4591912@bgtnsc05-news.ops.worldnet.att.net>,
 "James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes:
>You clearly have a poor organization. Try to think a bit more about
>modularity when designing packages. Either A and B should be
>merged into a single package, or pieces of A and B should be
>moved from one package to the other.

A has a large amount of code but a very small specification. It would
be correct to embed A in B, however this would make B very large.
By having A as a package, B can be fairly small. A has a distict purpose
(Memory Management) and I would like to isolate all of this in one file.

Other than merging A and B there is nothing that can be moved between
them and maintain correctness. A is used by B and by no other package,
all of the procedures in A are used by B.

Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[John Cupak]

What about using a private package?

John

"Steven Murdoch" <news01+Steven.Murdoch@cl.cam.ac.uk> wrote in message
news:at4unv$m2r$4@pegasus.csx.cam.ac.uk...
> In article <mailman.1039530902.542.comp.lang.ada@ada.eu.org>,
>  "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
> >A private child's spec can see in the private part of its parent.
>
> This was the case I needed, making the spec private fixed my problem.
>
> Thank you,
> Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <ErnJ9.188712$GR5.63282@rwcrnsc51.ops.asp.att.net>,
 "John Cupak" <Jcupak744@attbi.com> writes:
>What about using a private package?

Well I made the package spec of B.A private and it fixed the
problem. I assume this made the package private or do you mean
something else?

When I tried to make the package body of B.A private but this
gave the error "cannot have private package body".

Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[Robert A Duff]

news01+Steven.Murdoch@cl.cam.ac.uk (Steven Murdoch) writes:

>... A is used by B and by no other package,
> all of the procedures in A are used by B.

Then A is really part of the implementation of B, so it should be
"private package B.A is...".

You can also use subunits, but child packages are a bit more flexible.

- Bob

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <wccsmx5yimi.fsf@shell01.TheWorld.com>,
 Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>news01+Steven.Murdoch@cl.cam.ac.uk (Steven Murdoch) writes:
>
>>... A is used by B and by no other package,
>> all of the procedures in A are used by B.
>
>Then A is really part of the implementation of B, so it should be
>"private package B.A is...".

I think this is what I have done - and it works. My code is equivalent
to the example below. This works and seems to be the best way to do it.

-- b.ads
package B is
   procedure Proc_B;
private
    type Private_Type is new Integer;
end B;
--

-- b.adb
with B.A;
package body B is
   procedure Proc_B is
      Temp: Private_Type;
   begin
      A.Foobar(Temp);
   end;
end B;
--

-- b-a.ads
private package B.A is
   procedure Foobar(Temp: in Private_Type);
end B.A;
--

-- b-a.adb
package body B.A is
   procedure Foobar(Temp: in Private_Type) is
   begin
      null;
   end;
end B.A;
--

Thank you,
Steven Murdoch.

Re: Giving a package specification access to the private types of another package

[Stephen Leake]

news01+Steven.Murdoch@cl.cam.ac.uk (Steven Murdoch) writes:

> In article <slrnavbse4.5r4.randhol+news@kiuk0152.chembio.ntnu.no>,
>  Preben Randhol <randhol+news@pvv.org> writes:
> >make A a child package of B
> 
> It already is, but I have the same problem. I think if A is a child of
> B then the body of A can see the body of B, but the public specification of
> A cannot see the body of B (which is what I need).
> 
> One of the functions in A takes in a parameter of type C, where C
> is declared in the private part of B. This function is not used
> anywhere other than the body of B.

perhaps making A a private child of B will work.

Post some code for more help.

-- 
-- Stephe

Re: Giving a package specification access to the private types of another package

[SteveD]

"Steven Murdoch" <news01+Steven.Murdoch@cl.cam.ac.uk> wrote in message
news:at56fd$3cq$1@pegasus.csx.cam.ac.uk...
> In article <wccsmx5yimi.fsf@shell01.TheWorld.com>,
>  Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> >news01+Steven.Murdoch@cl.cam.ac.uk (Steven Murdoch) writes:
> >
> >>... A is used by B and by no other package,
> >> all of the procedures in A are used by B.
> >
> >Then A is really part of the implementation of B, so it should be
> >"private package B.A is...".
>
> I think this is what I have done - and it works. My code is equivalent
> to the example below. This works and seems to be the best way to do it.
>

The other choice is to make Private_Type visible as a private type.  That
is:

  -- b.ads
  package B is
     procedure Proc_B;
     type Private_Type is private;
  private
      type Private_Type is new Integer;
  end B;

Then the rest of the code works without modification.

Steve
(The Duck)

>
> Thank you,
> Steven Murdoch.
>

Re: Giving a package specification access to the private types of another package

[Grein, Christoph]

This is indeed the perfect design for your problem.

> I think this is what I have done - and it works. My code is equivalent
> to the example below. This works and seems to be the best way to do it.
> 
> package B is
>    procedure Proc_B;
> private
>     type Private_Type is new Integer;
> end B;
> 
> with B.A;
> package body B is
>    procedure Proc_B is
>       Temp: Private_Type;
>    begin
>       A.Foobar(Temp);
>    end;
> end B;
> 
> private package B.A is
>    procedure Foobar(Temp: in Private_Type);
> end B.A;
> 
> package body B.A is
>    procedure Foobar(Temp: in Private_Type) is
>    begin
>       null;
>    end;
> end B.A;

Re: Giving a package specification access to the private types of another package

[Jeffrey Carter]

Grein, Christoph wrote:
> This is indeed the perfect design for your problem.
> 
>>I think this is what I have done - and it works. My code is equivalent
>>to the example below. This works and seems to be the best way to do it.
>>
>>package B is
>>   procedure Proc_B;
>>private
>>    type Private_Type is new Integer;
>>end B;
>>
>>with B.A;
>>package body B is
>>   procedure Proc_B is
>>      Temp: Private_Type;
>>   begin
>>      A.Foobar(Temp);
>>   end;
>>end B;
>>
>>private package B.A is
>>   procedure Foobar(Temp: in Private_Type);
>>end B.A;
>>
>>package body B.A is
>>   procedure Foobar(Temp: in Private_Type) is
>>   begin
>>      null;
>>   end;
>>end B.A;

Perfect? That's a bit strong. It's a good design, but as given, I think 
that putting Foobar in B (perhaps with "is separate") is as good.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger

Re: Giving a package specification access to the private types of another package

[Grein, Christoph]

> Grein, Christoph wrote:
> > This is indeed the perfect design for your problem.
> > 
> >>I think this is what I have done - and it works. My code is equivalent
> >>to the example below. This works and seems to be the best way to do it.
> >>
> >>package B is
> >>   procedure Proc_B;
> >>private
> >>    type Private_Type is new Integer;
> >>end B;
> >>
> >>with B.A;
> >>package body B is
> >>   procedure Proc_B is
> >>      Temp: Private_Type;
> >>   begin
> >>      A.Foobar(Temp);
> >>   end;
> >>end B;
> >>
> >>private package B.A is
> >>   procedure Foobar(Temp: in Private_Type);
> >>end B.A;
> >>
> >>package body B.A is
> >>   procedure Foobar(Temp: in Private_Type) is
> >>   begin
> >>      null;
> >>   end;
> >>end B.A;
> 
> Perfect? That's a bit strong. It's a good design, but as given, I think 
> that putting Foobar in B (perhaps with "is separate") is as good.

I beg to differ. For this tiny example, you're right. But IIRC, the OP said that 
his package B.A was quite big and held a big part of the implementation stuff of 
B. Then child packages are the "perfect" design because you can split one big 
body (B) is several smaller children dedicated to specific subproblems.

Re: Giving a package specification access to the private types of another package

[Jeffrey Carter]

Grein, Christoph wrote:
>>Perfect? That's a bit strong. It's a good design, but as given, I think 
>>that putting Foobar in B (perhaps with "is separate") is as good.
> 
> I beg to differ. For this tiny example, you're right. But IIRC, the OP said that 
> his package B.A was quite big and held a big part of the implementation stuff of 
> B. Then child packages are the "perfect" design because you can split one big 
> body (B) is several smaller children dedicated to specific subproblems.

My recollection is that Foobar was large and A existed simply to make 
Foobar separate from B, in which case putting Foobar in B and making it 
separate still seems just as good. If it's A that's large and Foobar is 
only part of it, then a private package is probably better.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life

Re: Giving a package specification access to the private types of another package

[Steven Murdoch]

In article <3DF8C169.9020309@acm.org>,
 Jeffrey Carter <jrcarter@acm.org> writes:
>Grein, Christoph wrote:
>>>Perfect? That's a bit strong. It's a good design, but as given, I think 
>>>that putting Foobar in B (perhaps with "is separate") is as good.
>> 
>> I beg to differ. For this tiny example, you're right. But IIRC, the OP said that 
>> his package B.A was quite big and held a big part of the implementation stuff of 
>> B. Then child packages are the "perfect" design because you can split one big 
>> body (B) is several smaller children dedicated to specific subproblems.
>
>My recollection is that Foobar was large and A existed simply to make 
>Foobar separate from B, in which case putting Foobar in B and making it 
>separate still seems just as good. If it's A that's large and Foobar is 
>only part of it, then a private package is probably better.

I'm not sure if I was clear in my original post, but A was the big thing
I wanted to move out of B. I couldn't include the procedures that Foobar
uses inside the declaration of Foobar since one was a callback so had to be
part of a package and not a procedure. Also there are 3 public procedures
in A, but they are all part of the same conceptual purpose so belong
together.

Thanks for you help,
Steven Murdoch.