Re: objc runtime problem

[David Ayers]

Sounds good, but ...

if I read the code in sendmsg.c correctly, you would also have to add 
the receiver to __objc_get_forward_imp.  Then objc_msg_lookup could pass 
in the receiver.  Yet get_imp won't have a means to get the correct 
fowarding implementation, but that's no worse than before.

Would we only resort to asking the receiver if the supplied selector was 
untyped, potentially avoiding overhead (potential network traffic... or 
would that be incurred anyway, i.e use the formal protocol set in the 
NSDistantObject or do the type syncronisation while determining the 
forwarding function instead of during it's invokation)

We would be changing the signature of a function 
(__objc_get_forward_imp) that other code may be using (eventhough they 
shouldn't (yet it's not like we don't also rely on internal functions)), 
and more importantly the signature of functions suplied to a public hook 
would be altered.  How would other code be affected if it isn't updated?

Would it be plausible to introduce new variable for forwarding functions 
with the extra parameter? It would have precedence over the existing 
one.  Maybe we could also have a different name the 
__objc_get_forward_imp which takes the extra parameter and leave the old 
implementation... I'm not really sure it's such a good idea but I don't 
have a feeling for how much this function is used in other projects.  
The fact that __objc_msg_forward is a public hook of  objc-api.h makes 
me a bit weary.

Cheers,
David


Richard Frith-Macdonald wrote:

> It is currently impossible for these cases to work, because the 
> _objc_msg_forward() function takes a single argument (the selector to 
> look up), but the type information which should be associated with the 
> selector depends on the receiver, and the compiler may have provided 
> an untyped selector, or one with the wrong type info for the receiver.
>
> If sendmsg.c was modified to pass two arguments to the function, (the 
> second being the receiver), the function would be able to ask the 
> receiver for the type information and return a forwarding function 
> which would work for that receiver.