Re: objc runtime problem

[Richard Frith-Macdonald]

On Thursday, June 26, 2003, at 06:40  pm, David Ayers wrote:

> 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.

Yes ... it's only used in two places in the runtime, and is not 
declared in any headers ... so I think changing that should not be a 
problem.

>   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.

True.
Also, get_imp() has the class ... perhaps it would make sense to have 
three arguments, so you could pass it either the receiver or the class 
of any intended receiver, along with a flag to say which it is.  I'm 
not sure if this is worthwhile, but when the original hook was put in 
I'm sure it was felt that just passing the selector would be 
sufficient, and we've now found out that was wrong.

> 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)

If we want to handle circumstances where different objects have the 
same method name but with different types, I guess we would need to ask 
the receiver for the types every time.  In the case of the receiver 
being a DO proxy object, asking it for type info would (as you suggest) 
only involve a call to the remote process if the local proxy does not 
have the info cached (either as a result of a setProtocolForProxy: or 
because the proxy had been asked to fetch the type info earlier).

> 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.

I was hoping that, since __objc_msg_forward was introduced for GNUstep 
in the first place, no other code would be using it, and it could 
easily be changed.  However, I think you are right, and a safer 
solution might be to add a new hook (and perhaps comment
the old one as deprecated).