From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.0 required=3.0 tests=BAYES_40,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a0c:a085:: with SMTP id c5mr30096386qva.30.1600358286369; Thu, 17 Sep 2020 08:58:06 -0700 (PDT) X-Received: by 2002:a0c:f6c4:: with SMTP id d4mr12698990qvo.41.1600358286179; Thu, 17 Sep 2020 08:58:06 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!goblin3!goblin.stu.neva.ru!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 17 Sep 2020 08:58:05 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=96.247.204.159; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 96.247.204.159 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2e13e0ee-4b19-406b-a5e7-ed51dd4d300dn@googlegroups.com> Subject: Re: Visibility issue From: Jere Injection-Date: Thu, 17 Sep 2020 15:58:06 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:60183 List-Id: 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.