Re: Creating an NSInvocation from an NSMethodSignature
Re: Creating an NSInvocation from an NSMethodSignature
- Subject: Re: Creating an NSInvocation from an NSMethodSignature
- From: Michael Ash <email@hidden>
- Date: Tue, 12 May 2009 00:58:05 -0400
On Mon, May 11, 2009 at 9:04 AM, Mike Mangino
<email@hidden> wrote:
> I'm working on some changes to the OCMock framework to better support
> partial mocks and I'm a little stuck. In short, I'm trying to write a single
> method that I can attach to a class. I'm trying to make that method call
> through to the existing Mock recording code. It's based on NSProxy and
> expects to receive and NSInvocation.
>
> Creating the NSInvocation is easy. I'm not sure, however, how to fill in the
> parameters. The NSMethodSignature gives me the type encoding. Is there a way
> to use this information along with the address of the self parameter to fill
> in the params? I know how to get the type of each parameter, is there some
> way to convert the type string returned by getArgumentTypeAtIndex: to a
> size?
There is the NSGetSizeAndAlignment call, however I have heard that it
is buggy and you shouldn't use it.
One hack you might be able to do is to create a new NSMethodSignature
which uses that type as the return type, and then query
-methodReturnLength. This is ugly and evil, but it's the only other
built-in way I can think of.
Otherwise, you can build a comprehensive table for primitives without
much trouble. Where things get complicated is structs and unions.
Depending on your needs, you might punt on those entirely, or
implement a hardcoded check for common ones. You could of course
implement a full-fledged parser, but that's getting pretty crazy.
My suggestion would be, if at all possible, avoid creating the
NSInvocation manually at all. By far the nicest way to create an
invocation is by capturing it using the -forwardInvocation: method.
That way you create it using the same syntax you use to send any other
message, and the runtime takes care of all the icky details like
argument sizes.
Mike
_______________________________________________
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