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
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: Access parameters and accessibility
Date: Wed, 17 Dec 2014 07:02:56 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnm92al9.nrc.lithiumcat@nat.rebma.instinctive.eu>
References: <m6n3kr$t51$1@speranza.aioe.org> <m6onu3$6or$1@loke.gir.dk>
 <m6q27d$l4s$1@speranza.aioe.org> <m6q6eo$sgu$1@loke.gir.dk>
Injection-Date: Wed, 17 Dec 2014 07:02:56 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
	logging-data="26575"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/jJMP2ZIaBQGUU3fxmOus7"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:0npr3m0zNLtVD77GW/qkIyraBwc=
Xref: news.eternal-september.org comp.lang.ada:24063
Date: 2014-12-17T07:02:56+00:00
List-Id: <comp.lang.ada>

On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> Right. It's not 100% accurate, but trust me, you don't want to figure out 
> the rules to perfect accuracy. Moreover, if you don't use anonymous access 
> parameters and discriminants, and don't use 'Access in generic bodies, all 
> of the checking will be done at compile-time, so you can just use the old 
> "if it compiles, it must be right" strategy. Which is the best way to deal 
> with accessibility -- unless of course you are trying to implement it.

Now you got me really worried, because I thouhgt access discriminants
were safe. It was under that assumption that I actually started to
really like them.

More specifically, the pattern I caught myself using a lot looks like
the following:

   type Preprocessed_Data (Input_Data : access Input_Data_Type) is record
      Computed_Value_1 : Type_1;
      Computed_Value_2 : Type_2;
   end record;

   procedure Private_Helper (Data : in Preprocessed_Data) is
   begin
      --  Do stuff qui Computed_Value_* and maybe also with Input_Data
   end Private_Helper;

   procedure Process (Input_Data : in out Input_Data_Type) is
      Data : Preprocessed_Data (Input_Data'Access);
   begin
      --  Initialize Data.Computed_Value_*
      Private_Helper (Data);
   end Process;

For course, it means that Input_Data is actually aliased, so it must be
of a tagged type (or maybe a limited type works too?).

That way a strong connection is maintained between the original data and
whatever is derived from it, and it gets to be handled in a single value
rather than letting the number of arguments explode when there are
several preprocessed types or steps. Though I started building such
types to use generics that expected a single type/value.

Am I doing something danegerous here?
Should I try to find another pattern to achieve the same effects?

>From what I understood, here accessibility is statically known to be
fine, isn't it? Or is there a trap hidden in there?


Thanks for your thoughts,
Natasha