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!feeder.eternal-september.org!aioe.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Access parameters and accessibility Date: Tue, 16 Dec 2014 14:59:04 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1418763544 29214 24.196.82.226 (16 Dec 2014 20:59:04 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 16 Dec 2014 20:59:04 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24059 Date: 2014-12-16T14:59:04-06:00 List-Id: "Michael B." 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.