Re: Preventing private procedure visibility being made public through extension

[Robert Eachus <rieachus@comcast.net>]

On Saturday, May 20, 2017 at 1:33:27 PM UTC-4, Jere wrote:
> I tried to whittle this down to a small example, so forgive 
> the uselessness of the example itself.  I'm extending a 
> library with some of my own components and I want (if possible) 
> to allow my components to interact with the other library 
> components as seamlessly as possible.
> 
> Say a library provides a tagged type with the following procedure:
> 
> Base.ads
> *************************************************
> package Base is
>    
>    type Base_Param is tagged null record;
>    
>    type Base_Type is tagged null record;
>    
>    procedure Something
>       (Obj : in out Base_Type; 
>        Value : Base_Param'Class) 
>    is null;
>    
> end Base;
> 
> *************************************************
...
I think that the problem you are dealing with is the you started with one package and have never let go of that model.  You have two very different access patterns in mind (not access in the Ada sense).  So you need two packages to declare them.  Is there any reason to allow your clients to do anything with Base_Param other than pass it to subroutines you provide?  I think not.  I’m also going to avoid games like the Taft amendment,  Use it if you want to.

generic
  type Object is limited private;  
package Params is
begin
  type Param is limited private;
private
  type Access_Object is access Object;
  type Param is record
    Prev, Next: Access_Object;
  end record;
end Params;

with Params;
package Base is
  type Base_Type is tagged null record;
  type Base_Access is limited private;
  procedure Something
       (Obj : in out Base_Type; 
        Value : Base_Access);
private
  type Base_Access is access Base_Type;
  package My_Params is new Params(Base_Type);
end Base;  

package body Base
  –- declare any necessary operations of Base_Access here that way you only need 
  -- one body 
procedure Something
       (Obj : in out Base_Type; 
        Value : Base_Access)
  is begin null; end Something;
end Base;

I’ve used a mindset of you are going to be maintaining lists, databases or whatever of Base_Type, and would want Base_Type to be derived from Controlled or Limited_Controlled.  If you do need both Base_Type to be tagged, fine.  You will find that the two package model works fine if the classes, as such, are disjoint. But in Ada I have found that two tagged types in the same package eventually lead to madness.  If you have M (say 3) flavors of one type, and N (say 4) of the other, now you have M times N  (twelve_ sets of derived operations that can exist.  Adding another derivation will always break something.  Having the types declared in separate packages allows you to stay sane while trying to maintain the rats nest.  I’ve done the M plus N style with window managers where a dozen deep in one dimension (window manager) and six in another (program logic)  was version 1.0...