[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: objc runtime problem
Re: objc runtime problem
Fri, 27 Jun 2003 11:34:34 +0200
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.