2010 05 12Forwarding invocations
First, decide in methodSignatureForSelector:
whether to handle the call or not. If so, you'll need to return a signature describing arguments and return type of the method you'll call in place of the unknown one. To discard the call, just return nil. The signature itself is made up of type encodings, but you don't have to deal with those directly as you can use methodSignatureForSelector:
to return the signature of the method you'll actually call.
Then, handle the call in forwardInvocation:
. The NSInvocation
given as parameter gives you the original selector and its arguments. As a Cocoa method is actually a C function taking instance and selector as its first arguments, the unknown method's arguments actually start from the third argument.
Sample code time ! Here's a standard mutable dictionary ...
id dict = [NSMutableDictionary dictionaryWithObjectsAndKeys: @"John", @"name", [NSNumber numberWithInt:47], @"age", nil];
... that you can get and set on with valueForKey:
and setValue:forKey:
. As it's a bit verbose, let's use forward invocation to masquerade accessors :
// Call non existent getter - (id)age NSLog(@"age=%@", [dict age]); // Set a new age using a non existent setter - (void)setAge:(id)newAge [dict setAge:[NSNumber numberWithInt:48]];
To accomplish this, we'll add forward invocation to NSDictionary
to redirect zero parameter calls to call valueForKey:
and one parameter calls (starting with set
) to setValue:forKey:
.
@implementation NSDictionary (ForwardInvocation) // Determine if we can handle the unknown selector sel - (NSMethodSignature *)methodSignatureForSelector:(SEL)sel { id stringSelector = NSStringFromSelector(sel); int parameterCount = [[stringSelector componentsSeparatedByString:@":"] count]-1; // Zero argument, forward to valueForKey: if (parameterCount == 0) return [super methodSignatureForSelector:@selector(valueForKey:)]; // One argument starting with set, forward to setValue:forKey: if (parameterCount == 1 && [stringSelector hasPrefix:@"set"]) return [super methodSignatureForSelector:@selector(setValue:forKey:)]; // Discard the call return nil; } // Call valueForKey: and setValue:forKey: - (void)forwardInvocation:(NSInvocation *)invocation { id stringSelector = NSStringFromSelector([invocation selector]); int parameterCount = [[stringSelector componentsSeparatedByString:@":"] count]-1; // Forwarding to valueForKey: if (parameterCount == 0) { id value = [self valueForKey:NSStringFromSelector([invocation selector])]; [invocation setReturnValue:&value]; } // Forwarding to setValue:forKey: if (parameterCount == 1) { id value; // The first parameter to an ObjC method is the third argument // ObjC methods are C functions taking instance and selector as their first two arguments [invocation getArgument:&value atIndex:2]; // Get key name by converting setMyValue: to myValue id key = [NSString stringWithFormat:@"%@%@", [[stringSelector substringWithRange:NSMakeRange(3, 1)] lowercaseString], [stringSelector substringWithRange:NSMakeRange(4, [stringSelector length]-5)]]; // Set [self setValue:value forKey:key]; } } @endThe downside of this sample is that XCode will complain about unknown methods. Nonetheless, it's nice to see that you can do it.
A quick bench shows the get accessor 3% slower than valueForKey: and a set/get couple being 20 times slower.
For the problem about Xcode complaining about non existant methods, just create a interface for a category on the class declaring the methods but don't implement category. Xcode will see the declarations
On a separate issue do you have any experience with performance. How much overhead does this create. Eg. Time to make 10000 accesses on this as opposed to just using objectForKey: and setObject:forKey:
I have done something similiar in creating acccessors at runtime by adding methods to a class that all route their implementation to a single c function that parses the selector to handle the actual data accesses. Being written in c I have sense is that it is only a minor overhead. I'll post this later as I have time. (btw. A good deal of credit for this technique goes to Jeff Lamarche.)