From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Subject: Re: Access parameters and accessibility
Date: Wed, 17 Dec 2014 07:02:56 +0000 (UTC)
Date: 2014-12-17T07:02:56+00:00 [thread overview]
Message-ID: <slrnm92al9.nrc.lithiumcat@nat.rebma.instinctive.eu> (raw)
In-Reply-To: m6q6eo$sgu$1@loke.gir.dk
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
next prev parent reply other threads:[~2014-12-17 7:02 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 16:52 Access parameters and accessibility Michael B.
2014-12-15 17:54 ` Dmitry A. Kazakov
2014-12-15 18:48 ` Jeffrey Carter
2014-12-15 20:23 ` Michael B.
2014-12-15 21:02 ` Dmitry A. Kazakov
2014-12-16 1:10 ` sbelmont700
2014-12-16 13:57 ` Michael B.
2014-12-16 14:12 ` Georg Bauhaus
2014-12-16 21:34 ` sbelmont700
2014-12-17 14:30 ` Michael B.
2014-12-17 15:41 ` sbelmont700
2014-12-18 17:48 ` Michael B.
2014-12-17 16:03 ` Adam Beneschan
2014-12-18 16:07 ` Michael B.
2014-12-16 7:45 ` Randy Brukardt
2014-12-16 8:48 ` Stefan.Lucks
2014-12-16 20:47 ` Randy Brukardt
2014-12-16 21:24 ` Georg Bauhaus
2014-12-16 9:08 ` Natasha Kerensikova
2014-12-16 10:00 ` Dmitry A. Kazakov
2014-12-16 14:57 ` Robert A Duff
2014-12-16 19:46 ` Michael B.
2014-12-16 20:59 ` Randy Brukardt
2014-12-17 7:02 ` Natasha Kerensikova [this message]
2014-12-17 8:28 ` Dmitry A. Kazakov
2014-12-17 9:06 ` Natasha Kerensikova
2014-12-17 22:58 ` Randy Brukardt
2014-12-17 22:25 ` Randy Brukardt
2014-12-18 0:47 ` Shark8
2014-12-17 2:02 ` Adam Beneschan
2014-12-17 23:18 ` Randy Brukardt
2014-12-18 0:56 ` Robert A Duff
2014-12-18 1:17 ` Randy Brukardt
2014-12-18 5:29 ` Shark8
2014-12-18 23:12 ` Randy Brukardt
2014-12-18 8:27 ` Dmitry A. Kazakov
2014-12-18 21:20 ` Randy Brukardt
2014-12-19 12:16 ` Michael B.
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox