Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?
Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?
- Subject: Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?
- From: glenn andreas <email@hidden>
- Date: Fri, 1 Feb 2008 10:02:43 -0600
On Feb 1, 2008, at 9:25 AM, Jim Correia wrote:
I have a situation where I need to do some method introspection.
Given an arbitrary selector, and after having verified that
instances respond to the selector, I'd like to make sure the method
signature matches a particular form.
NSObjCValueType is listed as deprecated in the headers.
(Documentation says "Used internally by NSInvocation—do not use it
directly.")
The documentation for -methodReturnType and -getArgumentTypeAtIndex:
on NSMethodSignature says "This encoding is implementation-specific,
so applications should use it with caution."
Suppose I want to verify that a given method signature looks like an
action method.
if ([methodSignature numberOfArguments] == 3 &&
0 == strcmp(@encode(void), [methodSignature methodReturnType]) &&
0 == strcmp(@encode(id), [methodSignature getArgumentTypeAtIndex:
2]) {
}
Is testing the argument types in this manner, with @encode(), going
to be future proof?
No, it's not even "present proof" without additional work and/or a lot
restrictions.
The problem is that there are some edge cases of @encode with
structures and pointers to structures. I've seen examples of even
simple things like NSPoint and NSRect that produce different results
on a compile time @encode and getting the value from the runtime (this
gets worse for pointers to structures). According to the
documentation, it is suppose to be "{NSPoint=ff}", but I've seen
"{NSPoint}" as the value returned by the runtime (it may have been for
a pointer to an NSPoint, i.e., "^{NSPoint=ff}" vs "^{NSPoint}").
It also doesn't help that there are things that aren't made part of
the @encode (for example, an Altivec or SSE vector didn't use to come
back as anything at all, though this may have changed).
Obviously, there are cases (like a simple "return void, take an id")
that you won't run into these issues.
However, writing a string comparison routine that works to find
"compatible" @encode isn't that hard (i.e., handling cases of ignoring
structure contents). You'll also have to decide if signed vs unsigned
differences are "compatible" or not (since they have different
encodings). Also, is something that take an id compatible with
something that is declared as, say, "(NSControl *)" (which becomes "@"
vs "^{NSControl}" or "^{NSControl=....}")
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures,
fractals, art
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden