Re: Visibility issue

[Daniel <danielnorberto@gmail.com>]

Thank you for your answer Dmitry. Let me focus and change my example to easier go to the problem. I will write some question to your answer at the end of the example.

I didn't write it in the example for simplicity, but the user has to set a callback function.
This callback function is triggered in the internal implementation hierarchy packages. Let me show you the code within questions inside comments:

--- API SIDE: -----
package API.Callbacks
   type Handle is tagged private
   type pointer_to_Procedure is access procedure (Self : API.CAllbacks.Handle );
   procedure Set_Callback (Self: in out API_HandleCallBack; cp: CallbackProcedure  );
private
   type Handle is tagged record
      Hidden : Natural;
   end record;
  procedure Hidden_constructor (S: in out Handle'Class ; Hidden_content :Natural);
---------------
----- IMPLEMENTING SIDE: --------
private with API.Callbacks;
package body Internal.TASKS_Callbacks is

task body Caller is

 MyHandle : API.Handle;
 cp: CallbackProcedure := Get_from_pool_of_callbacks;
begin
  Hidden_Constructor (MyHandle, 6);
   --Cannot access to private part for API.Handle from here :(
  -- compiler says that Hidden_Constructor is not a visible entity of" Callbacks"
  -- I just wanted to build it to later call to the procedure:
   cp (MyHandle);
end Caller;

> Why is this a primitive operation? I would consider rather 
> 
> function Access_to_hide_content return User_type'Class; 
> 
> In presence of potential overriding things like these are usually 
> class-wide.
Using the updated example I've tried to use an Hidden_constructor using class-wide but compiler says
>"Hidden_Constructor" is not a visible entity of API.Callbacks.

.
> You can also use aggregation:
> type User_type is tagged with private;
> private 
> type User_type is tagged with record 
> Implementation : Private_Stuff; 
> end record; 
> 
> Private_Stuff may have its own hierarchy. This pattern works well with 
> limited types. You want the interface being non-limited, but the 
> implementation of limited in order to control/prevent excessive copying 
> and support in-place updates. So you make the interface a holder or a 
> smart pointer to the reference-counted implementation. 

Thank you for the idea, but I don't know if its really possible for the callback action I need to "call".
Lets say i extend Handle outside of API package hierarchy:

private with API.Callbacks;
package Internal.TASKS_Callbacks is
   type Handle_child is new API.Calbacks.Handle with null record;
  procedure Hidden_constructor (S: in out Handle_child; Hidden_content :Natural);
-------
package body Internal.TASKS_Callbacks is

task body Caller is

 MyHandle : Handle_child;
 mycall: CallbackProcedure := Get_from_pool_of_callbacks;
begin
  Hidden_Constructor (MyHandle, 6);
-- But now i need to trigger the callback procedure and that procedure is defined using Handle type, not the child Handle_child
-- how can i call the original callback procedure???
-- if I do the next 
mycall (MyHandle); --it raises that expect the father, not the child:

end task;

As you see.. how can i call from here the User callback procedure?