[Top][All Lists]

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

Re: objc runtime problem

From: David Ayers
Subject: Re: objc runtime problem
Date: Fri, 27 Jun 2003 11:34:34 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Richard Frith-Macdonald wrote:

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.


reply via email to

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