Re: Access type to member procedure of instance (Object Oriented programming in Ada)

[Adam Beneschan <adam@irvine.com>]

On Monday, November 19, 2012 3:59:14 PM UTC-8, Randy Brukardt wrote:

> >with Some_Package;
> 
> >procedure Main is
> >   Message : Some_Package.Message_Type;
> >begin
> >   Message.Print;
> >end Main;
> 
> >
> 
> >Is it possible to create a parameterless access type to the Message.Print 
> 
> >procedure?
> 
> >The following application refuses to compile:
> 
> >with Some_Package;
> >procedure Main is
> >   Message : Some_Package.Message_Type;
> >   Method_Ref : access procedure := Message.Print'Access;
> >begin
> >   Method_Ref;
> >end Main;
> 
> >The error message is: no selector "Print" for type "Message_Type" defined 
> >at some_package.ads:3

> I think this should work; if it doesn't, the error has something to do with 
> conventions. So there is probably a compiler bug here....

> I'm not certain what the convention of this procedure is (it might be 
> defined to be "intrinsic" somewhere, in which case you couldn't take 'Access 
> to it, I can't find such a rule on a quick check of the RM). 

6.3.1(4): The Intrinsic calling convention represents subprograms that are “built in” to the compiler. The default calling convention is Intrinsic for the following: ...

6.3.1(10.1/2) any prefixed view of a subprogram (see 4.1.3).

The AARM gives the reason immediately following:
 
Reason: The profile of a prefixed view is different than the “real” profile of the subprogram (it doesn't have the first parameter), so we don't want to be able to take 'Access of it, as that would require generating a wrapper of some sort. 

> But it surely 
> exists and should not report that "selector "Print" doesn't exist.

Yep, the error message appears to be wrong, but I can sort of understand it.  If the compiler knows that a prefixed view wouldn't be allowed here (as a prefix to 'Access), then since it has to do name resolution (in case Print is overloaded), it might be using a different search routine than it would use if it were processing a procedure call.  Or something like that.  


> In any case, our intent is that one could use this just like any other  
> procedure with the same profile. You can rename it, pass it as a formal 
> subprogram, call it of course, etc. So I would expect 'Access to work as 
> well, unless the RM explicitly says it does not.

I think the necessity of generating a wrapper, possibly a separate wrapper for every appearance of this kind of 'Access, is why the language designers decided not to allow it.  See AI95-252.  It's also why I was suggesting adding a new kind of access type, rather than changing the language to simply allow 'Access.

                            -- Adam