Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?
Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?
- Subject: Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?
- From: Jim Correia <email@hidden>
- Date: Fri, 1 Feb 2008 16:03:47 -0500
On Feb 1, 2008, at 11:02 AM, glenn andreas wrote:
No, it's not even "present proof" without additional work and/or a
lot restrictions.
Ugh...
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.
So the case presented above, for the void return type and id argument,
should be present and future proof?
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=....}")
In my test app, running on Leopard 32-bit (haven't tried Tiger or 64-
bit), NSControl * and id both @encode() and come back from
NSMethodSignature as "@".
Was this not always the case?
Jim
_______________________________________________
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