iTunes was messing about rebuilding the device I was trying to use for development, so I had time over lunch to write a new message dispatch system in the Objective-C language. “But wait,” you say, “Objective-C already has a message dispatch system!” True, and it’s better than the one I’ve created. But it doesn’t use blocks, and blocks are cool :-). In the discussion below, I’ll build up an implementation of a “recent items” list, which is discussed in Kevlin Henney’s presentation linked in the acknowledgements.
The constructor
One important part of an object system is the ability to make new objects. Let’s declare an object type, and a constructor type that returns one of those objects:
typedef id (^BlockObject)(NSString *selector, NSDictionary *parameters); typedef BlockObject(^BlockConstructor)(void);
I’d better explain signature of the BlockObject type. Objects can be sent messages; what we’re doing is saying that if you execute the object with a selector name, the object will dispatch the correct implementation with the parameters you supply and will give you back the return value from the implementation. That’s what objc_msgSend() does in old-school Objective-C. The constructor is going to return this dispatch block – actually it’ll return a copy of that block, so invoking the constructor multiple times results in multiple copies of the object. Let’s see that in action.
BlockConstructor newRecentItemsList = ^ {
BlockObject list = ^(NSString *selector, NSDictionary *parameters) {
return (id)nil;
}
return (BlockObject)[list copy];
}
Yes, you have to cast nil to id. Who knew C could be so annoying?
Message dispatch
An object that can’t do anything isn’t very exciting, so we should add a way for it to look up and execute implementations. Method implementations are of the following type:
typedef id (^BlockIMP)(NSDictionary *parameters);
With that in place, I’ll show you an example of the object with a dispatch system in place, and discuss it afterward.
typedef void (^SelectorUpdater)(NSString *selector, BlockIMP implementation);
BlockConstructor newRecentItemsList = ^ {
__block NSMutableDictionary *selectorImplementationMap = [NSMutableDictionary dictionary];
__block SelectorUpdater setImplementation = ^(NSString *selector, BlockIMP implementation) {
[selectorImplementationMap setObject: [implementation copy] forKey: selector];
};
BlockObject list = ^(NSString *selector, NSDictionary *parameters) {
BlockIMP implementation = [selectorImplementationMap objectForKey: selector];
return implementation(parameters);
};
return (BlockObject)[list copy];
};
The variables selectorImplementationMap and setImplementation are __block variables in the constructor block. This means that every time the constructor is called, the returned instance has its own copy of these variables that it is free to use and to modify. Let me put that another way: the entire message-dispatch system is encapsulated inside each instance. If a class, or even an individual instance, wants to implement message dispatch in a different way, that’s cool. It also means that an instance can change its own methods at runtime without affecting any other objects, including other instances of the same class. As long as the object still conforms to the contract that governs method dispatch, that’s cool too.
Implementing the recent items list
OK, now that we’ve got construction and messaging in place, we can start making useful objects. Here’s the implementation of the recent items list, where I’ve chosen to use an NSMutableArray for the internal storage, as with the dispatch map it’s an instance variable of the list. Needless to say you could change this to a C array, STL container or anything else without breaking external customers of the object.
BlockConstructor newRecentItemsList = ^ {
__block NSMutableDictionary *selectorImplementationMap = [NSMutableDictionary dictionary];
__block SelectorUpdater setImplementation = ^(NSString *selector, BlockIMP implementation) {
[selectorImplementationMap setObject: [implementation copy] forKey: selector];
};
__block NSMutableArray *recentItems = [NSMutableArray array];
setImplementation(@"isEmpty", ^(NSDictionary *parameters) {
return [NSNumber numberWithBool: ([recentItems count] == 0)];
});
setImplementation(@"size", ^(NSDictionary *parameters) {
return [NSNumber numberWithInteger: [recentItems count]];
});
setImplementation(@"get", ^(NSDictionary *parameters) {
NSInteger index = [[parameters objectForKey: @"index"] integerValue];
return [recentItems objectAtIndex: index];
});
setImplementation(@"add", ^(NSDictionary *parameters) {
id itemToAdd = [parameters objectForKey: @"itemToAdd"];
[recentItems removeObject: itemToAdd];
[recentItems insertObject: itemToAdd atIndex: 0];
return (id)nil;
});
BlockObject list = ^(NSString *selector, NSDictionary *parameters) {
BlockIMP implementation = [selectorImplementationMap objectForKey: selector];
return implementation(parameters);
};
return (BlockObject)[list copy];
};
Using the list
Here is an example of creating and using a recent items list. Thankfully, since writing this post literal dictionaries have appeared, so it doesn’t look so bad:
BlockObject recentItems = newRecentItemsList();
BOOL isEmpty = [recentItems(@"isEmpty", nil) boolValue];
NSDictionary *getArgs = @{ @"index" : @0 };
@try {
id firstItem = recentItems(@"get", getArgs);
NSLog(@"first item in empty list: %@", firstItem);
}
@catch (id e) {
NSLog(@"can't get first item in empty list");
}
Exercises for the reader
The above class is not complete. Here are some ways you could extend it, that I haven’t covered (or, for that matter, tried).
- Implement @"isEqual". Remember that no instance can see the ivars of any other instance, so you need to use the public interface of the other object to decide whether it’s equal to this object. You’ll need to provide a new method @"respondsToSelector" in order to build @"isEqual" properly.
- Respond to unimplemented selectors well. The implementation shown above crashes if you send an unknown message: it’ll try to dereference a NULL block. That, well, it’s bad. Objective-C objects have a mechanism that catches these messages, allowing the object a chance to lazily add a method implementation or forward the message to a different object.
- Write an app using these objects. :-)
Credit where it’s due
This work was inspired by Kevlin Henney’s presentation: It is possible to do OOP in Java. The implementation shown here isn’t even the first time this has been done using Objective-C blocks. The Security Transforms in Mac OS X 10.7 work in a very similar way. This is probably the first attempt to badly document a bad example of the art, though.
