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,a218418d0394661d
X-Google-Attributes: gid103376,public
From: Mark Lundquist <mark@rational.com>
Subject: Re: Extended revelation
Date: 2000/01/31
Message-ID: <3895FD0F.13EAB14E@rational.com>#1/1
X-Deja-AN: 580064636
Content-Transfer-Encoding: 7bit
References: <873q03$alb$1@nnrp1.deja.com>
Organization: Rational Software
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 2000-01-31T00:00:00+00:00
List-Id: <comp.lang.ada>

Jean-Marc Bourguet wrote:

> Hi all,
>
> I've a package which export to his users some usefull types and
> routines. In his private part, I've some more declarations
> which are exported to his child packages.
>
> My problem is that in one of the child package, I'd like to make
> public one of the private type (T).

That is, you want to export the type.  Its definition would remain
private, of course...

> I had though that
>
>         type T1 is private;
>     private
>         subtype T1 is T;
>
> but that's not valid.

Right.  A subtype declaration doesn't complete a private type
declaration.

> As renanimg does not apply to types I can't see
> an easy way to do it. Currently I'm using
>
>         type T1 is private;
>     private
>         type T1 is new T;

>
>
> I've also considered exporting T from the parent package, but neither
> solution please me.

You're right, privately deriving T1 from T does seem crummy (for one
thing, none of T's primitive operations will be publicly visible for
T1...)

It kind of seems like simply making T visible (still private) in the
parent package is what you want to do.  What do you find objectionable
about that?

If it "feels" right for T to be exported from the child package rather
than the parent, why not move the definition of T to the child
package?!?   Since T is already  private in the parent, I know you do
not have any other declarations in the visible part of the parent that
depend on the (full) definition of T.  Did you know that the body of the
parent can say "with Parent.Child;"?  If you have declarations in the
private part of the parent that require the full definition of T, then
perhaps you could solve it by moving those declarations to a private
child...?