[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: objc runtime problem

From: Richard Frith-Macdonald
Subject: Re: objc runtime problem
Date: Fri, 27 Jun 2003 09:28:50 +0100

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]