Re: accessibility check failed

[Serge Robyns <serge.robyns@gmail.com>]

On Tuesday, 1 December 2015 00:22:50 UTC+1, Randy Brukardt  wrote:
> You rarely need explicit access types in an Ada interface, as "in out T" and 
> "access T" are essentially the same for any tagged type T. Ada always allows 
> taking 'Access (or 'Unchecked_Access) of a tagged type parameter.

Initially I was using in/out and then I wanted to uni-formalize the interface because I need to take the access somewhere.  Now I'm rewriting it as per some previous suggestion without requiring to store the access parameter.

The only thing I do now wished it would be possible is to use multiple inheritance when merging all DOA class implementing their respective interfaces (in plural).


type abstract_interface is new limited interface and I1 and I2 and ....;
-- Below is not Ada
type concrete is new abstract_interface with I1_Impl and I2_Impl and ...;

Now I'm using mixin's but this require to write all overrides to call their respective implementations.
type concrete is new abstract_interface with record
I1 : T_I1_Impl;
I2 : T_I2_Impl;
....
end record;

> Claw ("Class Library for Ada and Windows", see rrsoftware.com) uses almost 
> no access types in its public interface, yet almost everything is 
> referential under the covers. Works fine, and puts all of the pain on the 
> implementor of the library (where it belongs) and not on the clients (like 
> access types do). (The one place where we had to use an access type was in a 
> single function return where return-by-copy didn't have the proper effect. 
> That's pretty rare.)

I'll attempt to build my interface the same way.
However I need to be able to change the returned object and have it reflected in the store.

> To answer your original question, once you use anonymous access types, all 
> accessibility checks become dynamic. That is, the accessibility of the 
> actual object is checked, no matter how many levels it's passed through. 
> Most likely, someone is operating on a local object and made a call on the 
> routine that's failing. Bob Duff calls that a "tripping hazard", and it 
> means that you can never reliably save anonymous access parameters outside 
> of the original subprogram (you can do it in the subprogram with a local 
> anonymous access object -- a hack on top of a hack, IMHO).

Now I do understand better why I found references on the web suggesting using named access types instead of anonymous. 

I've given the ARM section 3.10.2 a read to understand better this whole thing.  All I can say is that it isn't certainly not late evening lecture.  And I my case, I'm using a return and a qualified expression in one statement, for which I found a lot of "rules".

> In Ada 2012, you can "protect" an anonymous access with a precondition using 
> a membership test (but warning: these aren't tested in the ACATS and I don't 
> know if anyone has implemented them correctly). Something like:
> 
>     type Global_Access is access all Object;
> 
>     function Something (Acc : access Object; ...) return ...
>         with Pre => Acc in Global_Access;
> 
> In this case, if the object designated by Acc isn't defined globally, the 
> precondition will fail, so you can safely assign Acc to an object of 
> Global_Access in the body of Something. But, of course, that exposes part of 
> your implementation in the precondition, so it's not clear that's a good 
> thing.

Thanks.

Serge