Re: Type introspection with NSMethodSignature, deprecated NSObjCValueType?

FROM : Jim Correia
DATE : Fri Feb 01 22:03:47 2008

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 
> "" as the value returned by the runtime (it may have been 
> for a pointer to an NSPoint, i.e., "^{NSPoint=ff}" vs "^").
>
> 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 "^" 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