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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,b8b8a54001adc4d2
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!postnews.google.com!c13g2000cwb.googlegroups.com!not-for-mail
From: danmcleran@hotmail.com
Newsgroups: comp.lang.ada
Subject: Re: Possible Ada deficiency?
Date: 9 Jan 2005 09:15:47 -0800
Organization: http://groups.google.com
Message-ID: <1105290947.422412.195950@c13g2000cwb.googlegroups.com>
References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com>
   <wccy8f4orfp.fsf@shell01.TheWorld.com>
NNTP-Posting-Host: 172.148.93.145
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1105290951 8754 127.0.0.1 (9 Jan 2005 17:15:51
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 9 Jan 2005 17:15:51 +0000 (UTC)
User-Agent: G2/0.2
Complaints-To: groups-abuse@google.com
Injection-Info: c13g2000cwb.googlegroups.com; posting-host=172.148.93.145;
   posting-account=LSix6gsAAACmBFWMCbh6syCaua0lawvj
Xref: g2news1.google.com comp.lang.ada:7580
Date: 2005-01-09T09:15:47-08:00
List-Id: <comp.lang.ada>

>If so, I think it's a minor one. As Randy pointed out, if you don't
>want child packages to do something nasty, then don't create any child
>packages.

Yes. But what if I want to hide implementation detail from all others
who would write child packages?

>In any case, as some folks have pointed out, you should think of
"adding
>a child of X" as very similar to "modifying the source code of X".

This is also spelled out in the Ada95 rationale. While I understand the
reasoning, I would also argue that it would be advantageous for a
package writer to have the power to restrict what child packages can
see and modify.

>If you don't want people to do that, you need some extra-lingual
>mechanism to restrict them.

That's exactly right. I would propose adding a new keyword,
'concealed', to allow a package writer to hide certain areas from all
child packages. A trivial example:

package Some_Package is
type Not_So_Secret_Type is private; --Child packages can see here
type Some_Type is concealed; --Child package cannot see here
private
--Child package can change Not_So_Secret_Value
type Not_So_Secret_Type is record
Not_So_Secret_Value : Integer := 0;
end record
concealed
--Child packages cannot change Secret_Value directly
type Some_Type is record
Secret_Value : Integer := 1;
end record
end Some_Package

With the addition of this construct, a package writer can choose what
areas should be directly visible to child packages, and what areas
should not. This would force a child package to use the parent
package's public interface when dealing with objects of type Some_Type,
rather than having full visibility into Some_Type's internal
representation.