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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4885c546f6ddc77a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.190.104 with SMTP id gp8mr4577430pbc.4.1340395421430; Fri, 22 Jun 2012 13:03:41 -0700 (PDT) MIME-Version: 1.0 Path: l9ni7993pbj.0!nntp.google.com!news1.google.com!goblin3!goblin.stu.neva.ru!gandalf.srv.welterde.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Dynamic accessibility Date: Fri, 22 Jun 2012 15:03:35 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <192bee3d-c0d4-421d-b5f6-676bce2a38db@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1340395420 10854 69.95.181.76 (22 Jun 2012 20:03:40 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 22 Jun 2012 20:03:40 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original Date: 2012-06-22T15:03:35-05:00 List-Id: wrote in message news:192bee3d-c0d4-421d-b5f6-676bce2a38db@googlegroups.com... >On Thursday, June 21, 2012 2:43:06 PM UTC-4, Randy Brukardt wrote: >> Note that dynamic accessibility is always a bad idea, in that it provides >> "tripping hazard" -- you might get an exception from a few calls, but not >> others. It's especially bad as calls from unit tests most likely will >> work >> (they're not nested) while ones in actual programs might (calls in nested >> subprograms are much more common). > >This was my real concern with the access parameter accessibility; the >exception > depends entirely on what the client passes in (though the rumor in Ada > 2012 is > that there exists a mechanism to compare accessibility levels, so that one > might be > able to conditionally typecast an access parameter...?). Membership on access types in Ada 2012 includes the accessibility check. So you can write a precondition: Pre => Param in My_Access_Type which will fail if the accessibility check would fail. > It would seem a named type is preferable to an access parameter in any > case in which > assignment was necessary, especially in 2012 where there is not the 'in' > parameter > restriction for functions. I'm sure there is an example I cannot think > of, but what > are the legitimate reasons someone would want to pass an access parameter > and have > occasion to cast it? It seems backwards to provide a mechanism for > ensuring assignment > does not happen, and then implementing a workaround to allow it. I don't think there are any in Ada 2012. In Ada 95, you sometimes had to do that as a replacement for the missing "in out" parameter for a tagged object. Usually the trick was to "strip off" the accessibility check: Param.all'Unchecked_Access as you would have had to if the parameter was an "in out" parameter in a procedure. Note that "aliased" parameters help a bit here (they're guaranteed to live as long as the result of the function call, which is a bit longer than a "normal" parameter). > As always Mr. Brukardt, your responses are insightful and greatly > appreciated; thank you > for your continued help and support. And thanks for the praise; it's always nice to hear it since most of the feedback anyone hears is about the mistakes they made. :-) Randy. -sb