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-Received: by 2002:a5d:8b55:: with SMTP id c21mr2579858iot.188.1555971805565;
        Mon, 22 Apr 2019 15:23:25 -0700 (PDT)
X-Received: by 2002:a9d:6a43:: with SMTP id h3mr12910404otn.270.1555971805411;
 Mon, 22 Apr 2019 15:23:25 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!b2no73715itd.0!news-out.google.com!w17ni62itb.0!nntp.google.com!b2no73712itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 22 Apr 2019 15:23:25 -0700 (PDT)
In-Reply-To: <q9le67$cc0$1@franka.jacob-sparre.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=146.5.2.29;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 146.5.2.29
References: <a89faa70-f56a-4c33-967e-ddb24eaa8a8b@googlegroups.com>
 <q9le67$cc0$1@franka.jacob-sparre.dk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <16b6432c-c5f4-4504-887b-b7c35ad69e86@googlegroups.com>
Subject: Re: Anonymous Access and Accessibility Levels
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Mon, 22 Apr 2019 22:23:25 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader01.eternal-september.org comp.lang.ada:56177
Date: 2019-04-22T15:23:25-07:00
List-Id: <comp.lang.ada>

On Monday, April 22, 2019 at 4:11:20 PM UTC-6, Randy Brukardt wrote:
>=20
> As always, I suggest the following rules:
>=20
> (1) Do not use anonymous access types unless you absolutely need one of t=
he=20
> special capabilities that can only be done with them.
Agreed. Anonymous access types were a mistake =E2=80=94 I still stand by my=
 assertion that they should be eliminated from the language, even at the co=
st breaking backwards compatibility. [This would, of course, entail having =
real solutions to the problems that they "address" (like first-class subpro=
grams, closures, etc).]

> (2) Under no circumstances, do anything that cannot be checked statically=
.=20
> (So no one should use dynamic accessibility checks of anonymous access=20
> parameters or SAOAATs).
I'm unfamiliar with SAOAAT; but I agree with the premise: static-checking i=
s much preferable to run-time checking.

> (3) Think three times before depending upon access parameter dispatching =
and=20
> anonymous access-to-subprograms.
>    (A) If you find that you really need these things, complain to the ARG=
=20
> that you should be able to but cannot do these things with named access=
=20
> types. (This limitation is idiotic, as it requires repeating long=20
> declarations at every usage.) [I need help getting this fixed!!]
I'll keep it in mind.
(Weren't there supposed to be two other [sub]items here?)

> (4) Keep access types out of visible specifications (since they make memo=
ry=20
> management much harder, and locks in clients to suboptimal memory=20
> managment).
Indeed. Opaque/private types are quite nice.