Re: Dynamic accessibility

["Randy Brukardt" <randy@rrsoftware.com>]

<sbelmont700@gmail.com> 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