Re: Visibility issue

[Jere <jhb.chat@gmail.com>]

On Friday, September 11, 2020 at 6:37:29 AM UTC-4, Daniel wrote:
> Hello, 
> I want to use a tagged type as a link to communicate users of a library, in the way to make one part visible to them and also to hide some content that is only needed for the implementing of the library. 
> 
> Lets say i have the "Library" packages to expose things to users, and Implementing_Library packages to deal with the implementation: 
> 
> package Library.Users is 
> type User_type is tagged with private; 
> procedure foo_public (S: User_Type); 
> private 
> type User_Type is tagged with record 
> hide_content_to_user : Natural; 
> end record; 
> function Access_to_hide_content return User_type; 
> end Library.Users; 
> 
> private with Library.Users; 
> package Internal_Library_Implementing is 
> -- Some internal public developer stuff 
> private 
> --Here I want to get access to User_Type hide content. 
> end Internal_Library_Implementing; 
> 
> I've tried using "private with" but gnat says the next: 
> move subprogram to the visible part (RM 3.9.3(10)) 
> private function with tagged result must override visible-part function 
> 
> Compiler says Im forced to make all private User_type functions public. 
> So, are there more ways to see the hided content of this tagged type without extending the type itself in a child package? I needed to see this content outside of Library package.

Ada does not have a solution for the way you want to do it directly.  Languages like C++ (soon) 
and Java (already) have private modules (which are not the same as private packages), but 
Ada does not have an equivalent.  Now most compilers have a way to create a shared or static 
library and you can leverage this to get a similar scenario with Ada.  I would recommend 
a couple of different options:

1.  Break your design up more:
First make a singular package with public functions for both registering an implementation and
registering a client.  This holds your data structure where the callbacks are stored and searched
for and has low level data type calls for both a client and a implementer.

Next make two separate API packages, one for what you expect a client maker to use and one
for what an implementation maker might use.  These have high level data type and public
functions and they isolate all the client functionality to the client API package and all the 
implementer functionality to the implementer functionality  package.  Both of those will
internally (in the package body) use the low level calls from the first package I mentioned.

Finally, make either a static or shared library using these 3 packages and only expose the 
client API and the implementer API but not the low level package I first mentioned.  You
can then add that library to your normal code base and it is usable by the rest of your
code.

2.  Using package hierarchies.  Note, I know what your requirements you specified, but
if you are working inside Ada, then you are stuck using languages features provided by
it.  Others have suggested this, but I wanted to highlight this is the way I would probably
go at it because it makes sense with the type of design you are describing.  Make a top level
package that has all the low level stuff needed for both clients and implements in
the private section of that package.  I'll call it Base for simplicity.  Next, create your API hierarchy
as child packages under Base:  Base.Client_API for clients and then add an implementor child 
packages API also under Base:  Base.Implementer_API.  These both have access to the private
details of Base and also split up the public functions into two separate packages, one for 
clients and one for implementers.  Names can be obviously changed.

I realize that this doesn't meet your requirements completely, but Ada doesn't have any
analog to private modules (again not the same as private packages).  The first option
is most like what you want as you can use the library to hide the low level code and
only expose what public types and functions you want.  I provided the second option
because despite your requirements, that is the way I would tackle it as it clearly links
the relationships between everything similar to how the design is laid out.