From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID,
	T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d10596e187e90822
X-Google-Attributes: gid103376,public
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Private Children
Date: 1999/06/22
Message-ID: <m3so7k3bsp.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 492423149
References: <m3bteacxb8.fsf@mheaney.ni.net> <7klja3$c0p$1@nnrp1.deja.com>
 <376E70A5.F77E558D@averstar.com> <m3yahd4bet.fsf@mheaney.ni.net>
 <376E9EEB.322A3F39@averstar.com> <7kmoe4$o83@dfw-ixnews15.ix.netcom.com>
 <dale-2206991424480001@192.168.0.2>
NNTP-Posting-Date: Tue, 22 Jun 1999 00:56:54 PDT
Newsgroups: comp.lang.ada
Date: 1999-06-22T00:00:00+00:00
List-Id: <comp.lang.ada>

On 22 Jun 1999 14:24, dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>          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;"
> 
> It's still a bit ordinary though. The services offered in the public
> level can't rely on abstractions advertised in the private section,
> which I see as the major failure of this model.

Yes, but you can make use of them in the private region.  For example,
this would be a handy way to implement the full view (declared in the
private region) of a private type (whose partial view is declared in the
public region).

As was suggested in earlier posts:

1) Declare the private stuff in the private region of the root package.
   This way you can get rid of the intermediate package:

  package P is 
  private
    <private stuff here>
  end P;

  package P.C is
    <public stuff>
  private
    <private stuff that depends on private stuff in P>
  end P.C;


2) Declare the private stuff in a child, declare grandchildren that use
   that private stuff, and then rename the grandchildren as children:

  package P is
  end P;

  package P.Private_Stuff is
  private
    <private stuff>
  end;

  package P.Private_Stuff.C is
    <public stuff>
  private
    <private stuff that depends on private stuff in P.Private_Stuff>
  end;

  package P.C renames P.Private_Stuff.C;


The idea behind both of these schemes is to hide that fact that private
stuff is being used at all.  You don't what to expose publicly (in the
form of an intermediate package in the hierarchy) what is essentially an
implementation issue.