Re: Visibility issue

[Daniel <danielnorberto@gmail.com>]

El miércoles, 16 de septiembre de 2020 a las 17:05:07 UTC+2, Dmitry A. Kazakov escribió:
> On 16/09/2020 16:35, Daniel wrote: 
> > El miércoles, 16 de septiembre de 2020 a las 12:58:58 UTC+2, Dmitry A. Kazakov escribió: 
> >> On 16/09/2020 12:23, Daniel wrote: 
> >>> El miércoles, 16 de septiembre de 2020 a las 9:14:23 UTC+2, Dmitry A. Kazakov escribió: 
> >> 
> >>> Let's try to set and construct all hidden part details from Internal side, not from user side. 
> >> [...] 
> >> 
> >> Assuming "internal side" means "implementation side", this is in clear 
> >> contradiction with the code you posted. Your package Internal is 
> >> implementation and thus must be able to access whatever implementation 
> >> details it needs. 
> >> 
> >> Otherwise the API must provide means of construction. [Must be done 
> >> anyway in order to ensure the contract of Handle, provided default 
> >> initialization does not do that.] 
> > 
> > Then, I assume there is not a clear solution in Ada due to my imposed requirements
> Why? It is not in requirements, it is solely your design. 
> 
> I see no reason why the package Internal.CallbacksPool must be limited 
> to the public API. But I also see no reason why public API does not 
> provide means to construct fully functional handles.
> > So if the "Implementation side" needs all details,
> Implementation holds all details, per definition of implementation.
> > I only think in two options : 
> > 1.- Put the details of implementation in a children package in the API hierarchy, and try to explain users to don't "with it". I can try to make it really empty in the public part of the children package and only put what its needed for the implementation.
> 1. Children packages can be private. You cannot with them from outside. 
> 
> 2. Nothing forces you to put anything into the public part of a public 
> child package. With-ing it would expose nothing. 
> 
> 3. Packages can be nested and put into bodies of other packages. These 
> will not exist as library packages for the user. 
> 
> 4. Packages can have separate bodies if become too large. These bodies 
> are all private. 
> 
> There are lots of ways to make things private in Ada. 
> 
> [There are a few cases when privacy does not work in Ada, but none of 
> those are related to your problem]
> > 2.- Take out the details from "API hierarchy packages" to the "Implementation package hierarchy" and make visible everything I need in the "API side", and try also to explain users to don't use them.
> There is absolutely no need doing this.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de

OK, I think maybe I'm not explaining the problem precisely. Before going for the first option I'm curious to explore and to learn how can be done using the second option.

Let me start from scratch.
I want to make a design that fits the next requirements/limitations:

-There will be just one API package hierarchy that users can "with it"
-This API hierarchy will define a callback procedure type with a tagged type as an argument
-This tagged type argument of the callback procedure template will be defined in  API hierarchy including a set of procedures in order to access and convert information to users.

-There will be one or more internal packages not visible to users where information is created. Preferably not in API hierarchy
-The information will be passed to users with the callback procedure they already wrote and they already set using API.
- Internal information data types must be decoupled from API data types.
- Usually, information that is generated internally is bigger than the user needs to know, so API tagged type argument of the callback procedure needs to convert it

¿With these requirements/limitations, which design approach you think is better to start the design?