[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: objc runtime problem
Re: objc runtime problem
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
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
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).