Question

I am trying to implement a JSON-RPC solution, using a server connector object which obtains a list of available functions from a server somehow like

NSDictionary *functions = [server  
    callJSONFunction: @"exposedFunctions" arguments: nil];

which is a simplified description, since callJSONFunction actually triggers an asynchronous NSURLConnection.

An element of the function list consists of a string describing the objective c selector, the original function name which will be called using the mechanism mentioned above, the function signature and an optional array of argument names.

So for example a function list could look like this:

( 
    @"someFunctionWithArgumentOne:argumentTwo:" =  
    {  
        signature = @"@@:@@",  
        functionName = @"someFunction",  
        arguments = ( @"arg_one", @"arg_two" )  
    },  
    @"anotherFunction" =  
    {  
        signature = @"@@:",  
        functionName = @"anotherFunction"  
    }  
)

As soon as the function list was successfully retrieved, the selectors are added to the server connector instance using class_addMethod in a loop:

for ( NSString *selectorName in functions ) {  
    SEL aSelector = NSSelectorFromString ( selName );  
    IMP methodIMP = class_getMethodImplementation ( 
        [ self class ], @selector ( callerMethod: ) );
    class_addMethod ( [ self class ], aSelector, methodIMP, "v@:@@@@" );
}

where callerMethod: is a wrapper function used to compose the actual request, consisting of the function name as a NSString and an NSDictionary of the form

{ @"argument1_name" = arg1, @"argument2_name" = arg2, ... }

hence the signature "v@:@@". The callerMethod then invokes callJSONFunction on the server.

After this exhausting introduction (my bad, I just did not know, how to shorten it) I’ll finally get to the point: to cover the possibility of different numbers of arguments,
I defined the callerMethod like
- (void) callerMethod: (id)argument, ... { }
wherein I use the va_* macros from stdarg.h to obtain the passed arguments. But when I test the mechanism by invoking

[serverConnector someFunctionWithArgumentOne: @"Argument 1"  
    argumentTwo: @"Argument 2" ];

the first argument returned by id arg = va_arg ( list, id); is always @"Argument 2"!

I’d really appreciate all theories and explanations on why that happens. This thing is really driving me nuts!

Answer 1

Var-args do not map to regular argument passing quite so neatly. Encoding of arguments is actually quite architecture specific and rife with highly entertaining details that sometime seem like they are self-conflicting (until you discover the note about the one exception to the rule that makes the whole thing coherent). If you really want a good read [sarcasm intended], go have a look at how ppc64 handles long doubles sometime; there are cases where half of the double will be in a register and the other half on the stack. Whee!

The above long, and slightly frothy due to scarring, paragraph is to say that you can’t transparently forward a call from one function to another where the two functions take different arguments. Since an Objective-C method is really just a function, the same holds true for methods.

Instead, use NSInvocation as it is designed to hide all of the esoteric details of argument encoding that comprises any given platforms ABI.

In your case, though, you might be able to get away with class_addMethod() by defining a set of functions that define all possible combinations of argumentation. You don’t even really need to make a dictionary as you can use the dlsym() function to look up the correct function. I.e.

id trampolineForIdIdSELIdIdInt(id self, SEL _cmd, id obj1, id obj2, int) {
    ... your magic here ...
}

Then, you could translate the type string “@@:@@i” into that function name and pass it to dlsym, grab the result and use class_addMethod()….

I do feel an obligation to also mention this book as it is a sort of “whoah… man… if we represent classes as objects called meta classes that are themselves represented as classes then we can, like, redefine the universe as metaclasses and classes” ultimate end of this line of thinking.