Re: objc runtime problem

[David Ayers]

Richard Frith-Macdonald wrote:

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

Yet get_imp() only falls back to __objc_get_forward_imp after it has 
installed it's dtable and has not found the selector in its table.  So 
passing the class to __objc_msg_forward wouldn't give you more 
information than before.  I'm not sure really why get_imp() just doesn't 
return nil instead of attempting to return the forwarding function that 
might be used, as the class clearly doesn't implement the method 
directly but relies on the forwarding mechanism at runtime, which will 
then query the real receiver.

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

Hmm...  I do not know how the types selector mechanism in the objc 
runtime and the compiler work.  I'd expect all @selector(messageName) 
selectors to be untyped, yet the ones coded aVar = [anObject 
messageName] to be typed, if the declared reciever type is known and 
declarations for the selector's signature are found.

Now we are talking about an 'edge' case, when the receiver declared to 
implement the selector but acually doesn't but relies on forwarding, 
i.e. proxies like NSDistantObject and EOFault objects.  NSDistantObjects 
are not really my worry as an application generally has only a few of 
these and due to the general cost of remote messaging, some overhead is 
expected.  But EOFault objects in GDL2 applications are quite frequent 
and these proxies represent the basic building blocks.  Once a fault is 
'fired' it actually changes its class to the real class which implements 
the methods and the issue is no more.  Yet I still feel that we should 
be careful not to add unnecessary overhead.  If you really think we 
should always ask the receiver, please go ahead.

Yet if we do selectively ask the reciever, NSInvocation should probably 
always use an untyped selector, potentially converting a typed selector 
passed to setSeletor:.  Also all performSelector: variants should do the 
same.  So I understand that this could get hairy, and my not justify the 
probably minor performance gain by relying on typed selectors.

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

Does anyone know whether libFoundation uses it?  And if so whether it is 
actively maintained?  Then again, we would require the updated 
gnustep-base version for the 'fixed' gcc version, once libobjc is 
patched, so I still think going through the deprecation process is a 
good idea.  Maybe even commenting the old declarion out of the header 
with an appropriate comment but keeping it in the c-file.

Cheers,
David