Re: Visibility issue

[Daniel <danielnorberto@gmail.com>]

El jueves, 17 de septiembre de 2020 a las 17:00:38 UTC+2, Dmitry A. Kazakov escribió:
> On 17/09/2020 15:31, Daniel wrote: 
> > El miércoles, 16 de septiembre de 2020 a las 23:48:34 UTC+2, Simon Wright escribió: 
> >> I still don't understand _why_. 
> > ¿Why a tagged type in a callback function to send data to users? 
> > It wasn't my decision. It's an imposed requirement. 
> > (...yes sometimes I don't understand some requirements/limitations neither.) 
> > 
> >> Purely from the visibility aspect, 
> >> 
> >> package API is 
> >> function F return Integer; 
> >> private 
> >> Secret : constant := 42; 
> >> end API; 
> >> 
> >> private package API.Impl is 
> >> Altered : constant := Secret / 2; 
> >> end API.Impl; 
> >> 
> >> with API.Impl; 
> >> package body API is 
> >> function F return Integer is (Impl.Altered); 
> >> end API; 
> > 
> > ok Lets try to fit this requirement: 
> >> "There will be one or more internal packages not visible to users where information is created. Preferably not in API hierarchy"
> 1. API.Impl is not in the public hierarchy of API. 
Sadly requirement says to dont be neither public or private hierarchy part of the API.

> 2. Alternatively rename API.Impl into API_Impl. Move all secrets from 
> API to API_Impl. Use API_Impl with the body of API.
¿How exactly achieve to use API_Imp with the body of API?.... maybe using " .."separate" keyword an using nested child ?
Something like this?
----api.ads
package body API is
package body API_Imp is separate;

--api-api_Imp.ads
separate (API)
package body API_Imp is
Secret:  Natural:= 42; 
Altered : Natural:= Secret / 2; 
end 
If is not like this example, ¿How is your proposal? 

> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de