4

I'm trying to get a signature -- either an NSMethodSignature object or at least the type encoding string -- for a method declared in a protocol.

Asking the Protocol object itself isn't possible, since a) it doesn't implement methodSignatureForSelector:, and b) (as noted by Kevin below) it's deprecated.

The runtime function protocol_getMethodDescription returns a struct objc_method_description, which isn't described anywhere in the docs. It's in a public header, though -- <objc/runtime.h>:

struct objc_method_description {
    SEL name;
    char *types;
};

It seems reasonable to assume that the types string in there is going to be the same kind of signature encoding string used elsewhere, such as that expected by +[NSMethodSignature signatureWithObjCTypes:], and indeed, it looks correct.

What I can't track down is an actual, verifiable connection between that string and the type encoding process.

I can't think what else it would be, but still, do I have any justification for relying on this types string to be valid for interaction with other objects/functions on the same runtime? Note that I'm not writing encoding strings myself or expecting them to have a given format or value -- I only want to pass them from one part of the runtime/framework to another, i.e., retrieve an encoding string from a protocol and a) use it to generate an NSMethodSignature object if one isn't otherwise available, and possibly b) compare it to that of a runtime-generated NSInvocation (i.e., in -forwardInvocation:).

jscs
  • 63,694
  • 13
  • 151
  • 195
  • Note to the future: a major misunderstanding that prompted this question was that it was the runtime doing the original construction of the method signature, when in fact that's the compiler's job. – jscs Nov 02 '13 at 02:54

1 Answers1

5

Using Protocol as an object is deprecated. If you check the header <objc/Protocol.h> you'll see that pretty much everything on it is either not available in OBJC-2 or is deprecated as of OS X 10.5. What you can do is use protocol_getMethodDescription(), as you suggested, and pull out the types field. I'm not sure if it's actually officially documented that this is the type encoding of the method, but that is indeed what it is.

Lily Ballard
  • 182,031
  • 33
  • 381
  • 347
  • I guess maybe I shouldn't have included that bit about using the `Protocol` object, since I very quickly ruled it out. Thanks for the confirmation. There's no documentation of that field that I can find -- you think that this is just an "incomplete doc" issue? Any idea where in the runtime the construction of the string is buried? – jscs Jan 09 '12 at 21:02
  • @JoshCaswell: A lot of the underlying runtime stuff isn't particularly well-documented, but in this case it's pretty safe to assume that there's nothing else that this `types` field could possibly be, besides an `@encode`-string of the types. – Lily Ballard Jan 09 '12 at 21:17