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
	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: dale@cs.rmit.edu.au (Dale Stanbrough)
Subject: Re: Private Children
Date: 1999/06/23
Message-ID: <dale-2306991154580001@dale.cs.rmit.edu.au>#1/1
X-Deja-AN: 492758056
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> <m3so7k3bsp.fsf@mheaney.ni.net>
X-Complaints-To: abuse@cs.rmit.edu.au
X-Trace: emu.cs.rmit.edu.au 930102898 21984 144.205.16.58 (23 Jun 1999
 01:54:58 GMT)
Organization: RMIT
NNTP-Posting-Date: 23 Jun 1999 01:54:58 GMT
Newsgroups: comp.lang.ada
Date: 1999-06-23T01:54:58+00:00
List-Id: <comp.lang.ada>

Matthew Heaney wrote:

" 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:
  
   [example deleted]"


I don't particuarly like this scheme, because it relies on all the children
having access to the private details of the type.
 
 
"2) Declare the private stuff in a child, declare grandchildren that use
    that private stuff, and then rename the grandchildren as children:
 
 [example deleted]
 
 
 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."


Still not quite what i want to do. I would like to be able to build
subsystems where I have internal private packages whose type and
operations are visible within the private hierachy, but can also be
used to build (in the private parts of public packages) abstractions
that can be seen by everyone. (Having reread my original post i realise
now that i didn't mention private packages, which may have caused 
some confusion).

E.g.

   ----------------------------------------------------
   package P is
   end P;

   ----------------------------------------------------
   private package P.Private_Stuff is
      type PPS is private;
      blah blah blah;

   private
      <stuff>
   end;

   ----------------------------------------------------
   with P.Private_Stuff; use P.Private_Stuff;

   package P.Public_Stuff is
      type PPublic is private;
      blah blah blah;

   private
      type PPublic is -- a record with PPS components, 
                      -- or "new PPS;"
   end;
   ----------------------------------------------------

Of course there would have to be a restriction that the public section
of P.Public_Stuff could not export any of the information from the 
private package (e.g. no renames, subtypes etc).

Your 2nd proposal has the problem that implementation of types declared
in P.Private_Stuff can be seen by any child packages, so you loose any
ability to do hiding of abstractions -within- a hierachy.


Dale