Re: Private Children

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <376E9EEB.322A3F39@averstar.com>,
	Tucker Taft <stt@averstar.com> wrote:

>Oops, right you are.  The "idiom" I was misremembering was actually to
>create an extra level in the hierarchy, with all of the public
>children made into public children of this intermediate level,
>with the intermediate level spec having only a private part.
>You could then use library unit renaming to hide the presence
>of this intermediate level, if you wanted to.  I believe Robert
>Eachus suggested this approach originally.
>
>E.g.:
>    package P.Hidden_Level is
>    private
>       ... -- private stuff
>    end;
>
>    package P.Hidden_Level.C1 is
>      ...
>    private
>      ...  -- can see private decls of P.Hidden_Level
>    end;
>
>    with P.Hidden_Level.C1;
>    package P.C1 renames P.Hidden_Level.C1;
>
>-Tuck

 Thanks Tucker. This is a good idea. Also, consider,
 
       package P.Hidden_Level.Public_Level is
         type some-type is tagged private;
         -- some publicly exported services
       private
         ...
       end P.Hidden_Level.Public_Level ;

       package body P.Hidden_Level.Public_Level is
          -- implement exported services using the
          -- private services in the hierarchy since
          -- the body can see the private declarations
          -- of parent its units.
       end P.Hidden_Level.Public_Level;

 Might be a good technique for creating a cascade of child  packages
 where most of the hierarchy will consist of private specifications.
 The end of the hierarchy would be a public specification with a body   
 implemented using those private specifications.  This could prevent  
 premature use of a well-formed set of decompositions while still modeling  
 several levels of abstraction.   

 I wonder if this is also useful with Tucker's earlier example of 
 dispatching on privately declared operations. Seems there are some good        
 possibilities for powerful design strategies in this idea.  

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com