package organization (is this doable?)

package organization (is this doable?)

[Alejandro R. Mosteo]

So the problem: I'm binding a C library with several types/features that 
I'm splitting into several Ada packages. These packages must talk to each 
other sometimes in terms of auxiliary types that I want to hide from the 
user.

Even if I hide these types in a private package, or in the common parent 
private part, I cannot think of a way of exposing some subprograms in one 
package to the other, without also exposing them to users.

Example:

package Lib; -- Root package

package Lib.Feat_1; -- Some feature

package Lib.Feat_2; -- Another feature

private package Lib.Impl; -- Things I want to keep secret, conceptually 
they're in the private part of Lib IIUC.

Am I right that it is impossible for Feat_1 and Feat_2 to communicate 
using something that's private in Lib or Lib.Impl? That would mean 
exposing those private types in their respective public parts, which is a 
no go.

Right now I'm moving the things I don't want the user to see to a further 
child, e.g.:

Lib.Feat_1.Impl;
Lib.Feat_2.Impl;

There, implementation type names/subprograms are visible but the idea is 
that users never need these packages. And they can call each other. The 
thing is, I feel like I'm missing some way of organizing things to make 
what I want possible (that some types are never visible to the user). It 
feels like a diamond problem in that I need a child of two packages 
simultaneously (that could be entirely private).

Thanks,
Álex.

Re: package organization (is this doable?)

[Simon Wright]

"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:

> package Lib; -- Root package
>
> package Lib.Feat_1; -- Some feature
>
> package Lib.Feat_2; -- Another feature
>
> private package Lib.Impl; -- Things I want to keep secret,
> conceptually they're in the private part of Lib IIUC.
>
> Am I right that it is impossible for Feat_1 and Feat_2 to communicate
> using something that's private in Lib or Lib.Impl? That would mean
> exposing those private types in their respective public parts, which
> is a no go.

Lib.Feat_1 & 2 can see the private part of Lib, and the public part of
Lib.Impl.

What's wrong with putting stuff in the public part of Lib.Impl? No one
outside Lib can see it.

Re: package organization (is this doable?)

[Alejandro R. Mosteo]

On 29/06/2018 18:34, Simon Wright wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
> 
>> package Lib; -- Root package
>>
>> package Lib.Feat_1; -- Some feature
>>
>> package Lib.Feat_2; -- Another feature
>>
>> private package Lib.Impl; -- Things I want to keep secret,
>> conceptually they're in the private part of Lib IIUC.
>>
>> Am I right that it is impossible for Feat_1 and Feat_2 to communicate
>> using something that's private in Lib or Lib.Impl? That would mean
>> exposing those private types in their respective public parts, which
>> is a no go.
> 
> Lib.Feat_1 & 2 can see the private part of Lib, and the public part of
> Lib.Impl.
> 
> What's wrong with putting stuff in the public part of Lib.Impl? No one
> outside Lib can see it.

in Lib.Feat_1, doing a "with Lib.Impl" results in error
"current unit must also be private descendant of Lib".

I can do (in Feat_1) a "private with Lib.Impl", but then I can use these 
things only in private parts/body of Lib.Feat_1, which are also out of 
bounds for Lib.Feat_2, and viceversa.

Finally, I can make Lib.Impl not private and then it's just inelegant, 
since clients gain access to these declarations. Which is not a big 
issue, but is kind of a public pollution. This is basically what I'm 
doing now with Lib.Feat_X.Impl regular packages.

Thanks,
Álex.

Re: package organization (is this doable?)

[Simon Wright]

"Alejandro R. Mosteo" <alejandro@mosteo.com> writes:

> On 29/06/2018 18:34, Simon Wright wrote:
>> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
>>
>>> package Lib; -- Root package
>>>
>>> package Lib.Feat_1; -- Some feature
>>>
>>> package Lib.Feat_2; -- Another feature
>>>
>>> private package Lib.Impl; -- Things I want to keep secret,
>>> conceptually they're in the private part of Lib IIUC.
>>>
>>> Am I right that it is impossible for Feat_1 and Feat_2 to communicate
>>> using something that's private in Lib or Lib.Impl? That would mean
>>> exposing those private types in their respective public parts, which
>>> is a no go.
>>
>> Lib.Feat_1 & 2 can see the private part of Lib, and the public part of
>> Lib.Impl.
>>
>> What's wrong with putting stuff in the public part of Lib.Impl? No one
>> outside Lib can see it.
>
> in Lib.Feat_1, doing a "with Lib.Impl" results in error
> "current unit must also be private descendant of Lib".

In the spec, yes (or, as you say, 'with private', but of course you
can't make anything in the public part of Feat_1 (which is visible to
clients) depend on the private package Impl.

> I can do (in Feat_1) a "private with Lib.Impl", but then I can use
> these things only in private parts/body of Lib.Feat_1, which are also
> out of bounds for Lib.Feat_2, and viceversa.

'with Lib.Impl;' needs to be on Feat_*'s _body_.

So, put whatever you need Feat_1 to communicate to Feat_2 in Lib's
private part or Impl's public part (remember, it's only public to Lib's
body and Feat_*'s bodies.

package Lib is
private
   J : Integer := 42;
end Lib;

package Lib.Feat_1 with Elaborate_Body is
end Lib.Feat_1;

package Lib.Feat_2 with Elaborate_Body is
end Lib.Feat_2;

private package Lib.Impl is
   K : Integer := 41;
end Lib.Impl;

with Lib.Impl;
package body Lib.Feat_1 is
   A : Integer := J;
   U : Integer := Impl.K;
end Lib.Feat_1;

with Lib.Impl;
package body Lib.Feat_2 is
   B : Integer := J;
   V : Integer := Impl.K;
end Lib.Feat_2;

Re: package organization (is this doable?)

[Alejandro R. Mosteo]

On 29/06/2018 21:37, Simon Wright wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
> 
>> On 29/06/2018 18:34, Simon Wright wrote:
>>> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
>>>
>>>> package Lib; -- Root package
>>>>
>>>> package Lib.Feat_1; -- Some feature
>>>>
>>>> package Lib.Feat_2; -- Another feature
>>>>
>>>> private package Lib.Impl; -- Things I want to keep secret,
>>>> conceptually they're in the private part of Lib IIUC.
>>>>
>>>> Am I right that it is impossible for Feat_1 and Feat_2 to communicate
>>>> using something that's private in Lib or Lib.Impl? That would mean
>>>> exposing those private types in their respective public parts, which
>>>> is a no go.
>>>
>>> Lib.Feat_1 & 2 can see the private part of Lib, and the public part of
>>> Lib.Impl.
>>>
>>> What's wrong with putting stuff in the public part of Lib.Impl? No one
>>> outside Lib can see it.
>>
>> in Lib.Feat_1, doing a "with Lib.Impl" results in error
>> "current unit must also be private descendant of Lib".
> 
> In the spec, yes (or, as you say, 'with private', but of course you
> can't make anything in the public part of Feat_1 (which is visible to
> clients) depend on the private package Impl.
> 
>> I can do (in Feat_1) a "private with Lib.Impl", but then I can use
>> these things only in private parts/body of Lib.Feat_1, which are also
>> out of bounds for Lib.Feat_2, and viceversa.
> 
> 'with Lib.Impl;' needs to be on Feat_*'s _body_.
> 
> So, put whatever you need Feat_1 to communicate to Feat_2 in Lib's
> private part or Impl's public part (remember, it's only public to Lib's
> body and Feat_*'s bodies.

Thanks, Simon, I think I see a way forward now thanks to your precisions.

Álex.

> 
> package Lib is
> private
>     J : Integer := 42;
> end Lib;
> 
> package Lib.Feat_1 with Elaborate_Body is
> end Lib.Feat_1;
> 
> package Lib.Feat_2 with Elaborate_Body is
> end Lib.Feat_2;
> 
> private package Lib.Impl is
>     K : Integer := 41;
> end Lib.Impl;
> 
> with Lib.Impl;
> package body Lib.Feat_1 is
>     A : Integer := J;
>     U : Integer := Impl.K;
> end Lib.Feat_1;
> 
> with Lib.Impl;
> package body Lib.Feat_2 is
>     B : Integer := J;
>     V : Integer := Impl.K;
> end Lib.Feat_2;
>