comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Access parameters and accessibility
Date: Tue, 16 Dec 2014 14:59:04 -0600
Date: 2014-12-16T14:59:04-06:00	[thread overview]
Message-ID: <m6q6eo$sgu$1@loke.gir.dk> (raw)
In-Reply-To: m6q27d$l4s$1@speranza.aioe.org

"Michael B." <michaelb@example.com> wrote in message 
news:m6q27d$l4s$1@speranza.aioe.org...
> On 12/16/14 08:45, Randy Brukardt wrote:
>> We in the ARG call discussing accessibility a "trip to the Heart of
>> Darkness", and indeed, 3.10.2 is now informally called the "Heart of
>> Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the
>> desperate or foolhardy venture there.
>
> Heart of Darkness?! When reading this part of the ARM it felt a little bit 
> weird. But I had no idea it could be *that* bad ;-).
>
>> I had heaard about the issue that John mentions in this paragraph, but I
>> never understood it (I don't think Janus/Ada does it). I've had it 
>> explained
>> to me a couple of times, and I sort of understand it, but you'd have to 
>> pay
>> me to spend an hour finding an example and writing up an appropriate
>> explanation. It's that draining - I wouldn't do it for free. Sorry.
>
> Does that mean I should give up on that issue as I will never be able to 
> understand it?

Well, if you do understand it, we need you on the ARG. :-)

>> Besides, I agree with the others that it has nothing to do with OOP. Claw
>> only uses anonymous access parameters to get the effect of in out 
>> parameters
>> in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
>> noted, it doesn't work very well. Anonymous access parameters: just say 
>> no!!
>
> How can I avoid them when they are heavily used in so many libraries?

Get better-designed libraries.

> E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL 
> 2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found 
> examples of the usage of anonymous access parameters.
> You could argue that this is bad design, but rewriting all this code is 
> not really an option for me.
> And compared to writing GUIs in plain C it seems to be the lesser of two 
> evils.

You could write GUIs using Claw (see www.rrsoftware.com), which surely does 
not have this mess. (Of course, I'm biased about Claw.) No bare C required. 
That's true of many other libraries as well. One thing about GUI and 
containers libraries -- much like the weather, if you don't like one, there 
are plenty of others to use.

Anonymous access parameters tends to make calls ugly (because they have to 
be filled with 'Unchecked_Access), clutter the object declarations (because 
of the need to explicitly declare them aliased), and also have what Bob Duff 
calls a "tripping hazard" -- the fact that Program_Error might be raised if 
they are passed a local object. But that depends on how they are used in the 
implementation, so no users can know whether or not it is safe to pass a 
local.

...
>> The only thing to worry about vis-a-vis dynamic accessibility checking is
>> that the object has to have a lifetime the same or longer than the access
>> type.
>
> At least this rule is easy to understand :-).

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.

                            Randy.





  reply	other threads:[~2014-12-16 20:59 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 [this message]
2014-12-17  7:02       ` Natasha Kerensikova
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