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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,5dacec64c8c879fa
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.238.198 with SMTP id vm6mr16417921pbc.3.1328691109103;
        Wed, 08 Feb 2012 00:51:49 -0800 (PST)
Path: 
 wr5ni585pbc.0!nntp.google.com!news2.google.com!postnews.google.com!c20g2000vbb.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Preventing Unchecked_Deallocation?
Date: Wed, 8 Feb 2012 00:49:47 -0800 (PST)
Organization: http://groups.google.com
Message-ID: 
 <ca07bff2-cb4f-4cd4-a191-249cb229840b@c20g2000vbb.googlegroups.com>
References: 
 <33a35da4-6c3e-4ab4-b58f-a9d73565d79a@t30g2000vbx.googlegroups.com>
 <ad427e2f-efdb-4e34-b4cf-ee55a3f8e9f5@f14g2000yqe.googlegroups.com>
 <f4c34323-d0d8-4315-aaaa-31c0119e2ba4@n6g2000vbz.googlegroups.com>
 <jgqg6s$oaj$1@adenine.netfront.net>
NNTP-Posting-Host: 83.3.40.82
Mime-Version: 1.0
X-Trace: posting.google.com 1328691108 20529 127.0.0.1 (8 Feb 2012 08:51:48
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 8 Feb 2012 08:51:48 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: c20g2000vbb.googlegroups.com; posting-host=83.3.40.82;
 posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
X-Google-Web-Client: true
X-Google-Header-Order: HUALESNKRC
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13,gzip(gfe)
Content-Type: text/plain; charset=ISO-8859-1
Date: 2012-02-08T00:49:47-08:00
List-Id: <comp.lang.ada>

On 7 Lut, 07:26, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:

> A basic design rule is: the reserved word access must not appear in the visible
> part of a package specification.

Don't worry. It will appear in the user package, where yours is
withed.
The smart user will define his own access types and will make pointers
from your objects at the nearest opportunity and there's lots of them
if the type in question is, for example, tagged.

> If you follow this rule, I think your problem
> will disappear.

This rule will irritate the user, because it will make creating
pointers one line more difficult. ;-)

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com