Cocoa and the Builder Pattern

There’s been a nice discussion about the Builder pattern on Twitter today. The Builder pattern is a nice tool to have, particularly because it addresses a few common problems.

What Builder Pattern?

In short, the Builder pattern is a pattern where you have one object that you configure that then creates another object based on that configuration. The nice thing here is that you can first build your object step by step, like you’d e.g. do with NSMutableString, but then the actual construction of the object happens in one go. Very handy for immutable objects.

Usually, a setter for a Builder object returns self, like retain or autorelease do. That way, you can create something in Java or C++ that almost looks like Objective C:

Image theImage = (new Image.Builder)->SetWidth(100)->SetHeight(80)->SetDepth(8)->Build();

Where the Build() method releases the builder and returns the actual, immutable Image object.

Extending init methods

When you add a parameter to an initializer in Objective-C, it is annoying. You usually add the parameter to the initializer, then create a compatibility version with the old method’s name that calls the newer version with a default value for the extra parameter.

Java and C++ have solved that problem by allowing you to specify default values for parameters, but they don’t maintain binary stability that way. If you add a parameter, you still have to recompile, but at least you don’t need to change your code.

I guess one fix would be if ObjC supported default arguments to a parameter that would simply result in the creation of a second version of this initializer with the label and parameter removed:

-(id) initWithBanana: (NSBanana*)theBanana curvature: (CGFloat)curvature = 5
{
    // magic happens here
}

Would be the same as writing:

-(id) initWithBanana: (NSBanana*)theBanana curvature: (CGFloat)curvature
{
    // magic happens here
}


-(id) initWithBanana: (NSBanana*)theBanana
{
    return [self initWithBanana: theBanana curvature: 5];
}

Of course, you’d still need at least one parameter, because ObjC has no way of knowing what part of the message is the name, and what is the label for the second (for init there could be special code, I guess, but what for a -exfoliateCow:withSpeed: method?). And defaulting to -initWithBanana if the first parameter has a default is obviously not always desirable either. It would solve the annoyance of telescoping constructors, at the least.

The Builder pattern doesn’t have this problem. Each parameter has a setter that you use to set it. A new builder could have defaults for all parameters when it is created. Then you change the ones you want to customize, and call -build on it to get the new object. If a new setter is added, that’s fine. You don’t call it, you get the default. The maintainers only add the one setter, no compatibility method needed.

Thread safety and immutable objects

The easiest way to get thread safety is to prohibit data from changing. If data is immutable, there is nothing to be synchronized between threads,and no need for one thread to wait for the other. However, immutable objects are also annoying, as they need to be fully specified in their init method.

A case where this is a problem in Cocoa is NSImage. NSImage is an immutable object by convention, but not actually. It is an object that has its own builder built in. You are expected to know that, for an NSImage to be thread safe, you are expected to create it, set its attributes, draw something in it, and then stop messing with it, treating it as an immutable, read-only object from then on.

The problem is, nobody enforces it. NSImage is a perfectly mutable object, with setters and getters. There is no exception thrown when you violate this verbal contract. Of course Apple could have added a “makeImmutable” method to NSImage that causes those exceptions to happen when you try to edit an instance. But then they’d have to add code to each setter that errors (Or at the least use some aspect-oriented-programming mechanism to inject code before every setter that performs this check automatically).

The Builder pattern would solve that: They can have a huge, private constructor on NSImage that changes with every release to add new parameters and initialize that immutable object, while the Builder would present a stable and convenient API to all clients. There would not be any setters on NSImage.

But it is ugly…

Admittedly, it feels a bit inelegant to build an object that builds an object. The way NSImage works is so much nicer. But Mike Lee actually offers a neat approach that works almost as well:

Just pass in a list of properties. This could be a dictionary of properties, or even just a variadic argument list like -dictionaryWithObjectsAndKeys: takes it. You’d define a constant for each possible property (that way if you mis-type the parameter name the compiler tells you, which you don’t get from a raw string). Internally, this constant could even hold the actual name of the property, even if it is never exposed as a method in the public header. So, all your constructor would do is call [self setValue: properties[key] forKey: key] in a loop, once for every element.

You get the same effect as labeled parameters (if you put the keys first, even more so). You also get the same effect as optional parameters. The binary ABI never changes, so that’s good, too. The only downside is you need to pass every parameter as an object, and you lose compile-time type checks. OTOH you gain compile-time errors when you try to change the object after creating it (because it declares no setters).

Is it worth all that work?

Admittedly, I haven’t had to add parameters to the init method of a public class that often. Nonetheless, I think Mike’s approach and the Builder pattern both are useful things to keep in mind if you ever come up with a class that can be created in numerous configurations (and is likely to gain new properties in the future) but should then be immutable. Class clusters and plug-in classes seem like a typical place where you might need this.

Are your rectangles blurry, pale and have rounded corners?

One common problem with drawing code in Cocoa (iOS and Mac OS X) is that people have trouble getting crisp, sharp lines. Often this problem ends up as a question like “How do I get a 1-pixel line from NSBezierPath” or “Why are my UIBezierPath lines fuzzy and transparent” or “Why are there little black dots at the corners of my NSRect”.

The problem here is that coordinates in Quartz are not pixels. They are actually “virtual” coordinates that form a grid. At 1x resolution (i.e. non-Retina), these coordinates, using a unit commonly referred to as “points” to distinguish them from act pixels on a screen (or on a printer!), lie at the intersections between pixels. This is fine when filling a rectangle, because every pixel that lies inside the coordinates gets filled:

filled_rectangle_between_pixels

But lines are technically (mathematically!) invisible. To draw them, Quartz has to actually draw a rectangle with the given line width. This rectangle is centered over the coordinates:

coordinates_between_pixels

So when you ask Quartz to stroke a rectangle with integral coordinates, it has the problem that it can only draw whole pixels. But here you see that we have half pixels. So what it does is it averages the color. For a 50% black (the line color) and 50% white (the background) line, it simply draws each pixel in 50% grey. For the corner pixels, which are 1/4th black and 3/4ths black, you get lighter/darker shades accordingly:

line_drawing_between_pixels

This is where your washed-out drawings, half-transparent and too-wide lines come from. The fix is now obvious: Don’t draw between pixels, and you achieve that by moving your points by half a pixel, so your coordinate is centered over the desired pixel:

coordinates_on_pixels

Now of course just offsetting may not be what you wanted. Because if you compare the filled variant to the stroked one, the stroke is one pixel larger towards the lower right. If you’re e.g. clipping to the rectangle, this will cut off the lower right:

coordinates_on_pixels_cut_off

Since people usually expect the rectangle to stroke inside the specified rectangle, what you usually do is that you offset by 0.5 towards the center, so the lower right effectively moves up one pixel. Alternately, many drawing apps offset by 0.5 away from the center, to avoid overlap between the border and the fill (which can look odd when you’re drawing with transparency).

Note that this only holds true for 1x screens. 2x Retina screens exhibit this problem differently, because each of the pixels below is actually drawn by 4 Retina pixels, which means they can actually draw the half-pixels needed for a 1 point wide line:

coordinates_between_pixels_retina

However, you still have this problem if you want to draw a line that is even thinner (e.g. 0.5 points or 1 device pixel). Also, since Apple may in the future introduce other Retina screens where e.g. every pixel could be made up of 9 Retina pixels (3x), you should really not rely on fixed numbers. Instead, there are now API calls to convert rectangles to “backing aligned”, which do this for you, no matter whether you’re running 1x, 2x, or a fictitious 3x. Otherwise, you may be moving things off pixels that would have displayed just fine:

coordinates_on_and_between_pixels_future_retina

And that’s pretty much all there is to sharp drawing with Quartz.

The fast road to unit tests with Xcode

Supposedly Xcode has unit test support. I’ve never seen that work for more than two Xcode revisions. So I’ve come up with a minimal unit test scheme that works reliably.

1) Add a “command line tool” target (Foundation application, C++ application, whatever makes sense). Put your test code in its main.m or whatever. After each test, print out a line starting with “error: ” if the test failed. If you want to be able to see the successes as well, start them with “note: “. Keep a counter of failed tests (e.g. in a global). Use the number as the app’s return value of your main().

2) Add a “Run Shell Script” build phase to this target, at the very end. Set it to run ${TARGET_BUILD_DIR}/${PRODUCT_NAME}. Yes, that’s right, we make it build the unit test app, then immediately run it. Xcode will see the “error: ” and “note: ” lines and format them correctly, including making the build fail.

3) Optionally, if you want these tests to run with every build, make that command line tool target a dependency of your main app, so it runs before every build. Otherwise, just make sure your build tester regularly builds this test target.

4) Add a preprocessor switch to the tests that lets you change all “error:” lines into “warning:” instead. Otherwise, when a test fails, you won’t be able to run it in the debugger to see what’s actually going wrong.

How to write a compiler

A bytecode interpreter feeding instructions through it.Since there isn’t that much beginner info out there about this topic, here’s a very rough run down of what I know about the basics of writing your own compiler, in particular about how the CPU works and how to generate code for it.

CPU/bytecode interpreter

A bytecode interpreter works just like a CPU, the difference being that it is in software, while the CPU is actual hardware. So all a fake or real CPU does is take a list of instructions and fetch them one by one.

To properly do that, there is one variable (in a real CPU, this is a register) that contains the position of the current instruction. This is called the program counter or PC for short, and is basically just the memory address of whatever command it is to execute.

Once an instruction finishes, the CPU adds to the PC to make the pointer point at the next instruction (or in the case of a conditional or loop, it rewinds the PC back to the start of the loop, or jumps over the ‘else’ section, or whatever.

So it’s fairly easy to create a bytecode interpreter. It’s just a loop:

#define NO_OP        0
#define PRINT        1
#define END          2
struct Instruction { int instructionType; int param1; int param2; };
Instruction *currentInstruction = LoadCodeFromDisk();

while( currentInstruction )
{
    if( instructionType == NO_OP )
        currentInstruction++;
    else if( instructionType == PRINT )
    {
        DoPrint( currentInstruction->param1, currentInstruction->param2 );
        currentInstruction++;
    }
    else if( instructionType == END )
        currentInstruction = NULL;
    else
        exit(1); // UNKNOWN INSTRUCTION! BLOW UP!
}

So all that generating machine code or byte code is, is really adding items to an array of structs. Of course, if you want to generate Intel machine code it’s a little more complicated, because instructions can be different size, so you can’t use a classic array, but you can write the raw data to a file or memory block just the same.

Generating code that jumps

If you’ve ever programmed BASIC, you’ve probably seen the following program:

Text with arrows indicating the progression from Print to Goto back to Print1 PRINT "Hello World"
2 GOTO 1

This is an endless loop. Line 1 prints some text to the screen, and line 2 jumps back to line 1. Once line 1 is done, we continue to line 2 again, which jumps back to line 1, forever and ever until someone turns off the computer. So all GOTO does is change the currentInstruction from our above example, the program counter.

currentInstruction = 1;

You can implement GOTO the same way in your bytecode interpreter. However, since you usually don’t know what address your code will be loaded at (and it definitely won’t be address 1), you will generally write your code so it jumps relative to the current instruction’s location. So our version of GOTO, the JUMPBY instruction, would be

currentInstruction += currentInstruction->param1;

For our pseudo-machine-code:

PRINT "Hello World"
JUMPBY -1

With this instruction under your belt, you can quickly implement conditional statements like if. An if-instruction is simply an instruction that looks at a location in memory (whose address could be provided as param2) and if that location is 1 (true), jumps by param1. Otherwise it does the usual currentInstruction++.

The conditional GOTO is the basic building block of all flow control. If/else:

Flow from 1,2,5,6 for true case,  2,3,4,6 for false case.1 FOO=1
2 GOTO 5 IF FOO
3 PRINT "Foo is false."
4 GOTO 6
5 PRINT "Foo is true."
6 END

loops:

1 FOO=0
2 GOTO 6 IF FOO
3 PRINT "Repeating."
4 DO_SOMETHING_THAT_COULD_CHANGE_FOO
5 GOTO 2
6 PRINT "End of loop"
7 END
While loop execution order: 1,2,3,4,5,2 and then if FOO is 1, from there to 6 and 7, otherwise on to 3 again etc.

Note that bytecode has no operators, no expressions, no precedence. You provide operations in the order it is supposed to execute them. If you want to compare two strings, you do so in the instruction at the top of the loop, save its result to FOO, then loop over FOO:

1 FOO=COMPARE("a","b")
2 GOTO 6 IF FOO
3 PRINT "Repeating."
4 DO_SOMETHING_THAT_COULD_CHANGE_FOO
5 GOTO 1
6 PRINT "End of loop"
7 END

(Note how line 5 jumps to line *1* here, i.e. every time through the loop, the condition is evaluated, then the conditional GOTO tests it)

Retroactive code generation

Now how do you generate code for this? How do I know, before I have read and generated the individual instructions, what line the GOTO in line 2 will have to jump to?

Well, you don’t. Instead, what you do is write out the GOTO as

2 GOTO 0 IF FOO

and then later, when you reach the end of the loop in line 5, where you write out the GOTO that jumps back to the condition, you simply change the destination of line 2 after the fact. This is usually fairly easy if you write a function for parsing every syntax element. Take the following C-like program:

strcpy( txt, "a" );
while( compare(txt,"b") )
{
    print("repeating");
    do_something_that_could_change_txt();
}
print( "End of loop" );

You’d have a function CompileOneLine() that reads one line and looks at the first word. If it is “if” it calls CompileIfLine(), if it is “while” it calls CompileWhileLine(), “print” – CompilePrintLine() etc.

CompileWhileLine would look something like:

void CompileWhileLine()
{
    int conditionOffset = ReadAndCompileExpression( "FOO" );
    int conditionalGotoOffset = WriteInstruction( "GOTO IF", 0, "FOO" );
    if( NextChar() == '{' )
    {
        SkipChar('{');
        while( NextChar() != '}' )
            CompileOneLine();
    }
    else
        CompileOneLine();
    int gotoOffset = WriteInstruction( "GOTO", conditionOffset );
    SetDestinationOfGoto( conditionalGotoOffset, gotoOffset );
}

And since we call CompileOneLine() again to read the lines inside this while statement, we can nest while statements.

Variables

As demonstrated, this byte-code has one big downside: How do we do variables? We can’t put the variables in with the code, because that would mean that when a function calls itself, it would use the same variables as its previous iteration. So we need some sort of stack to keep track of the most recent function’s variables.

And this is what the stack in programming languages like C is: The code for a function has a prolog and an epilog. That is, a few instructions at the start, before any actual commands that the function contains, where it makes the stack larger to reserve space for the variables we need, and a few more after the end to get rid of them again. In our BASIC-like pseudocode, this could look like:

PUSH 0 // Reserve space for 3 int variables:
PUSH 0
PUSH 0
// ... actual code goes here
POP // Get rid of no longer needed 3 int variables
POP
POP

Now since we sometimes need a variable just for a short while (e.g. FOO for holding the loop condition’s result to hand off to the conditional GOTO instruction), it would be kind of awkward to find our variables by counting from the back of the stack. So for that we have a base pointer. A base pointer is another variable/register, like our program counter before. Before we push our variables on the stack, we write the size of the stack into the base pointer.

SavedBasePointerPUSH basePointer // Save the old basePointer (for whoever called us)
SET_BASEPOINTER // Write current stack size to basePointer
PUSH 0
PUSH 0
PUSH 0
// ... actual code goes here
POP
POP
POP
POP_BASEPOINTER // Restore the saved base pointer into the basePointer

Now, to use a variable, we can simply access it relative to the basePointer, i.e. basePointer[0]=1. No matter how many variables we add, these numbers stay the same for the lifetime of our function.

ParametersOnStackAnd once we have this, we can also implement parameters. Parameters are simply variables at a negative offset. Since whoever calls us pushes parameters on the stack right before calling us, they all can be found right before our saved basePointer. So basePointer[-2] is parameter 1, basePointer[-3] parameter 2 etc. This means the parameters need to be pushed in reverse order, but that’s all there is to it.

Returning

Given the above, it comes as no surprise that you can’t just return from your function. You need to make sure that, before you return, your clean-up code runs. So what we usually do is, we make a note of the position at which the clean-up code starts, put a RETURN statement right at its end, and then whenever the code wants to return, we just write the return value somewhere on the stack, GOTO the clean-up code and let it return.

Of course, you’ll have to remember all spots that GOTO that code, because when you write them, the clean-up code won’t have been written yet, and fill it out in retrospect. But if you got this far, that’s all old hat to you.

Strings and other (bigger) data

Illustration of a few instructions followed by a block of data with arrows from the instructions to their particular stringsAs you may have noticed, our instructions only have two ints as parameters. What if you need to e.g. provide a format string to printf? Well, you’ll need an instruction that loads a string constant. Pushes its address on the stack, which the print command can then grab and display.

Commonly, what one does is simply write the strings in the same file (or memory block) as the bytecode, e.g. right after the actual instructions, and then load the whole thing into RAM. Since you know how big your block of code is after you’ve written it, you can retroactively fill out the offset from the instruction to the string it is supposed to push on the stack, and at runtime, the instruction can use currentInstruction +n to get a pointer to it and push that on the stack.

And that’s pretty much how you create a bytecode interpreter and generate bytecode (and in a simplified form, this is how you generate machine code).

Cocoa: String comparisons and the optimizer

Woman in front of a mirrorA while ago, a friend came to me with this bit of code:

NSString *a = @"X";
NSString *b = @"X";
if( a == b )
{
    NSLog(@"Same!");
}

“How come it works with the == operator? Didn’t you have to call isEqualToString: in the old days?”

Before we answer his question, let’s go into what he implicitly already knew:

Why wouldn’t == work on objects?

By default, C compares two pointers by simply comparing the addresses. That is logical, fast, and useful. However, it is also a little annoying with strings, arrays and other collections, because you may have two collections that still contain identical objects.

If you have the phone books from 2013 and 2014, do you just want to compare the numbers 2013 and 2014 and be told: “No that’s not the same phone book”, or are you actually interested in whether their contents are different? If nobody’s phone book entry changed in a particular city, wouldn’t you want to know that and save yourself the trip to the phone company to pick up a new phone book?

Since all Objective-C objects are pointers, the only way to do more than compare the addresses needs some special syntax. So NSString offers the isEqualToString: method, which, if the pointers do not match, goes on to check their contents. It compares each character to the same position in the second string to find out whether even though they’re not the same slip of paper, they at least have the same writing on it.

So why does the code above think they’re the same?

After all that, why does the code above think they are the same object after all? Doesn’t a point to the @"X" in the first line, b to the @"X" in the second line?

That is what is conceptually true, what a naïve compiler would do. However, most compilers these days are smart. Compilers know that a string constant can never change. And they see that the contents of both string objects pointed to by a and b are the same. So they just create one constant object to save memory, and make both point to the same object.

There is no difference for your program’s functionality. You get an immutable string containing “X”.

However, note that there is no guarantee that this will happen. Some compilers perform this optimization for identical strings in one file, but not across files. Others are smarter, and give you the same object even across source files in the same project. On some platforms, the string class keeps track of all strings it has created so far, and if you ask for one it already did, gives you that, to save RAM. In most, if you load a dynamic library (like a framework) it gets its own copy of each string, because the compiler can not know whether the surrounding application actually already has that string (it might be loaded into any arbitrary app.

Mutability is important

This is a neat trick compilers use that works only with immutable objects, like NSString or NSDictionary. It does not work with NSMutableString. Why? Because if it put the same mutable string into a and b, and you call appendString: on a, b would change as well. And of course we wouldn’t want to change our program’s behaviour that way.

For the same reason, NSString may be optimized so that copy is implemented like this:

-(id) copy
{
    return [self retain];
}

That’s right. It gives you the same object, just with the reference count bumped, because you can’t change this string once it has been created. From the outside it looks the same. Copy gives you the object with its retain count bumped, so you can release it safely once you’re done with it. It behaves just like a copy. The only hint you may have that this happened is that instead of an NSString with reference count owned solely by you, you get one with a reference count of 2 whose ownership you share with another object. But that’s what shared ownership is about after all.

Of course, this optimization doesn’t work with NSMutableString.

What I take away from this

So if someone walks up to you and shows you code that uses the == operator where it should really be checking for content equality, and argues that “it works, so it is correct”, now you’ll know why it just happens to work:

It’s a fluke, and if Apple decides to switch compilers or finds a better way to optimize performance or memory usage that requires them to no longer perform this optimization, they might just remove it, and this code will break, because it relied on a side effect. And we don’t want our code to break.

The universal catch-all singleton

Personified application delegate creating objects by cracking eggsOne bad habit I see time and time again is filling up your application delegate with junk that has no business being in there.

Avoid putting stuff in your app delegate.

What is the application delegate?

By definition, the application delegate is a controller. Most model classes are standard Apple classes. Those that aren’t are slightly smarter collections of these classes. Most view classes just display the model and forward a few IBActions to the controller in a dynamic way, so are inherently reusable as well (even if not always the particular arrangement of their instances).

The controllers, on the other hand, aren’t really reusable. They glue all this stuff together. They’re what makes your application your application, along maybe with a few bindings. So, again by definition, the application delegate is the least reusable part of an application. It’s the part that kicks everything off, creates all the other controllers and has them load the model and views.

Reusability is best!

The whole point behind OOP was to reduce bugs, speed up development, and help structure your code by keeping it grouped in reusable components. The best way to maintain this separation of components and permit re-using parts of it in different projects, is to keep the boundaries between components (e.g. objects) clean and distinct.

Objects have a clear hierarchy. The top creates objects lower down and gives it the information they need to operate correctly for your application. Nobody reaches up the hierarchy, except maybe to notify whoever created it of occurrences in the form of delegate messages. That way, the more application-specific your code gets, the fewer other objects know about it. The further down you get, the more reusable.

Moving operations or instance variables that are shared by several objects in your application into the application delegate, and having other objects reach straight up through NSApplication.sharedApplication.delegate to get at it, goes head-on against this desire, and turns your carefully separated code into an inseparable glob of molten sludge. Suddenly *everybody* includes the most application-specific header your application contains.

Don’t lie to yourself

The application delegate is one of the singletons every application contains. Its name is misleading and fuzzy. If you see it as a place to hold code “relevant to the application as a whole”, there is pretty much nothing that is off-topic for it. It is the universal, catch-all singleton.

So why not be honest to yourself: Whenever you add code to the application delegate, and you’re not just doing it to react to a delegate method from NSApplication and create a controller to perform the actual action in response, what you are really doing is create a singleton.

As we all know, singletons have a use, but having many singletons is a code smell. So avoid them if you can, but if you feel you can’t, be honest to yourself and actually make it a separate singleton (or find one whose purpose these operations fit).

Just say no to the application delegate as the universal singleton.

Update: If this hasn’t convinced you, here’s another blogger with a more CoreData-centric discussion of the issue, coming to the same conclusion: Don’t abuse the app delegate.

What a block really is

BlocksLegoBrickAfter quite a while of thinking that Objective-C blocks did some mean magic on the stack, it simply took me seriously using C++’s lambdas (their implementation of the concept) that I realized what blocks are.

Effectively, a block is simply a declaration of a class, plus an instantiation of one instance of that class, hidden under syntactic sugar. Don’t believe me? Well, let’s have a look at C++ lambdas to clear things up:

MyVisitorPattern( [localVariableToCapture]( MyObject* objectToVisit ) { objectToVisit->Print(localVariableToCapture); }, 15 );

The red part is a C++ block. It’s pretty much the same as an Objective-C block, with two differences:

  1. You explicitly specify which local variables to capture in square brackets.
  2. Instead of the ^-operator, you use those square brackets to indicate that this is a block.

Seeing the captured variables specified explicitly listed here, like parameters to a constructor, made me realize that that’s really all that a block is. In-line syntax to declare a subclass of a functor (i.e. an object whose entire purpose is to call a single of its methods), and return you an instance of that class. In ObjC-like pseudo-code, you could rewrite the above statement as:

@interface MYBlockSubClass : NSBlock
{
    int localVariableToCapture;
}

-(id) initWithLocalVar: (int)inLocalVariableToCapture;

-(void) runForObject: (MyObject*)objectToVisit;

@end

@implementation MYBlockSubClass
-(id) initWithLocalVar: (int)inLocalVariableToCapture
{
    self = [super init];
    if( self )
        localVariableToCature = inLocalVariableToCapture;
    return self;
}

-(void) runForObject: (MyObject*)objectToVisit
{
    objectToVisit->Print(localVariableToCapture);
}
@end

and at the actual call site:

MyVisitorPattern( [[MYBlockSubClass alloc] initWithLocalVar: localVariableToCapture], 15 );

The difference is that C++ (and even more so Objective-C) automatically declare the class for you, create the instance variables and constructor for the variables you want to capture, pick a unique class name (which you can see in the stack backtraces if you stop the debugger inside a block) and instantiate the class all in a single line of code.

So there you see it, blocks aren’t really black magic, they’re 99% syntactic sugar. Delicious, readability-enhancing syntactic sugar. Mmmmmh…

PS – Of course I’m simplifying. Objective-C blocks are actually Objective-C objects created on the stack, which you usually can’t do in plain Objective-C, though it can be done with some clever C code if you insist.

A more magical approach to blocks

That said, there is a fancier way for a compiler developer to implement blocks that also makes them 100% compatible with regular C functions:

If you implement a function in assembler, you can stick additional data onto the end of a function and calculate an offset between an instruction and the end of the function (e.g. by just filling the end of the function with a bunch of 1-byte No-Ops). This means that if someone duplicates a block, they’ll duplicate this data section as well. So what you can do is declare a struct equivalent to the captured variables, and implement your code with (pseudocode):

void    MyBlock( void )
{
struct CapturedIVars * capturedIVars = NULL;

currentInstruction:
    capturedIVars = pointer_to_current_instruction + ivarsSection-currentInstruction;

    // Block's code goes here.
    
    goto ivarsSectionEnd; // Jump over ivars so we don't try to execute our data.
    
ivarsSection:
    assembler_magic_to_reserve_some_space;
ivarsSectionEnd:
}

Now you can use the capturedIVars pointer to access the data attached to your function, but to any caller, MyBlock is just a plain old function that takes no arguments. But if you look at it from a distance, this is simply an object prefixed with a stub that looks like a function, so our general theory of blocks being just special syntax for objects holds.

I presume this is how Swift implements its blocks, because it really doesn’t distinguish between blocks and functions.

Why The Hulk needs to be a non-CGI TV series

HulkPoster

Prompted by a comment by Lou Ferrigno, and keeping in mind that I’m neither a show-runner, nor a writer, and that I effectively got into reading comics through the Bill Bixby Hulk TV series, here’s my take on why the Hulk movies so far didn’t work, and why we should go back to that TV series’ recipe.

My opinion on the Hulk movies so far is split: The first Hulk movie (The Hulk, 2003) had an amazing cast (Jennifer Connelly and Eric Bana, for all intents and purposes, are Bruce and Betty), and the first half showed an amazing insight into the Hulk and Bruce. However, it then spiraled into an odd ‘the goodness of your heart can solve everything’-Anime-esque resolution of the plot that, while not bad in absolute terms, just isn’t what the Hulk is about for me. The Hulk, to me, has always been about science, albeit science gone wrong, and about the internal battle of good versus evil externalized. Ang Lee, on the other hand, completely internalized the external battle in the end, and added some real groaners, like the gamma-poodles.

So while I think the first movie is the better movie from a moviemaking standpoint, and has the better actors (even though Nick Nolte’s character is horribly over the top, that’s not his fault, and he plays excellently, as ever), I have to give credit for being the better Hulk movie to 2008’s The Incredible Hulk. Edward Norton is a great actor even on bad days, and while Liv Tyler’s characters never really ‘click’ with me, she plays her role well. The star of the movie, though, is Tim Roth, who plays an amazing foil to our jade giant. The movie is mostly an action movie, but manages to play off the evil twin relationship between the Hulk and Abomination, and Bruce and Betty’s relationship, and Bruce’s battle for calm just enough to keep me happy.

And this is the only way a 10-foot Hulk about whom everyone knows that he is Bruce Banner can work. As a force of nature in a disaster movie. As a projectile pointed at a target to eliminate it. You can do Hercules with it, and Godzilla vs. King Ghidhorah. It’s how Joss Whedon used him in The Avengers (played by an amazing, but totally different Mark Ruffalo). But here he also gave a large part to Bruce Banner, genius, scientist. And played him off all the other characters on the team. He gave us the Bruce Banner who is in control to a degree, who is aware he has power, and often uses that threat to much greater and much more precise effect than he could ever use the Hulk. Like in the scene where Black Widow tracks him down. Like in the comics when he runs away from the convent with Betty.

The 10-foot Hulk is the brawn on a team, where depth and emotion can be provided by the other characters. But wouldn’t any other morphing character or strongman from the Marvel universe fit that bill just as well? Hercules? Luke Cage? Guido? Wonderman? Don’t DC have dozens of characters that fit the bill just as well? Solomon Grundy? Doomsday? What is it that makes Marvel’s Hulk a so much more interesting character?

I think Lou Ferrigno hit on the point why the Hulk movies so far never quite worked: The Hulk isn’t supernatural. Sure, on average he’s a 7′ guy with Mr. Universe muscles, but people who are that tall have been reported in real life. He’s an outlier, but he isn’t the height of a building. The original, grey Hulk was even more normal in height, and looked like the rather pretty Boris Karloff ideal of Frankenstein’s monster. Nobody except for his friend Rick Jones knew he was the Hulk, nor that it was a man who transformed into that monster.

The stories ranged somewhere between Monster matinee and Jekyll and Hyde, with Marvel’s characteristic soapy drama and angst thrown in for good measure. It was a mythicalized story about a man trying to control his anger before he hurts the ones he loves, often failing. While even then the Hulk already tossed around tanks like strongmen throw beer kegs, and had the occasional cross-over with the rest of the Marvel universe, the root of the story was a Banner-centric Jekyll and Hyde story. He was low-powered to fit into an otherwise normal world. Watch the BBC’s Jekyll TV series, then compare it to Peter David’s split-personality Hulk, for an example of how this can work on TV.

If the Hulk is a gigantic monster and there are other monsters in the show, it quickly becomes yet another Hercules story, which has been done really well since the beginning of TV and special effects. Heck, Lou Ferrigno has played that exact part. And that’s what makes the Hulk so much better than all of the characters that came before him, be it Jekyll and Hyde, Frankenstein, Frankenstein’s monster, Hercules, the berserkers… the Hulk can be all of these. But the Hulk can’t be all of these in a single one-hour movie.

It stands to reason therefore, that he works best in a TV series: The Hulk came from a comic series. In the pilot, he is basically Jekyll and Hyde meets Frankenstein, and you want to make him low-powered. But different from J&H, you can choose to tell Hercules stories, disaster movies, monster movies, horror shows, spy stories, relationship triangles and everything else we’ve seen since 1962 in the comic.

That’s where the Hulk’s advantages over all the other shows are: At its heart, it is Mary Shelley’s and R.L. Stevenson’s genius, but it can be everything else to keep it fresh. You can’t really do that deep stuff well with a 10-foot-CGI Hulk. But the Hulk has transformed before. Particularly during the era where Peter David wrote and Dale Keown drew the Hulk, it was established that both the grumpy but reasonably eloquent 6’7″ grey Hulk of the first issue and the monosyllabic 7′ green Hulk “giant baby” with the Arnold Schwarzenegger hairstyle were in continuity. As was the 8 foot “Bruce Banner’s head on a Hulk body” variant. As was a monster with an external spine.

It would be easy to spin off a Hulk TV series from The Avengers by having Banner try to cure himself as in the comics, turning him back into a more Ferrigno-ish, human, Frankenstein’s-Monster-Hulk. The mental child in Hercules’ body. Then you could advance the character, mutated by Banner’s attempts at healing himself. He could turn into the grey “Joe Fixit” Hulk in Las Vegas for half a season. He could save his cousin and thus cause a She-Hulk. He could meet the Abomination, Rick Jones as another Hulk, or even an evil Hulk like Dick Durock’s in the old TV series.

He could learn about prehistoric Hulks (TV series), about Banner’s childhood trauma and his guilt and how it caused Joe Fixit. Then they could go back to the action and give us the Leader as the mental opposite of the Hulk, compared to Abomination’s physical one. They could integrate the various Hulks and Banner into one during that time, making both Sam Stearns and Bruce Banner face the freakishness of the bodies their minds are trapped in, but drawing opposite conclusions.

Every Avengers movie could be connected to continuity through incidents that make him big again. Banner tries to split the Hulk from himself, which turns him into a mindless monster with Banner nowhere to be seen. The Leader could draw gamma energy from him to strengthen himself, which returns back into him in an earth-shattering season finale when the Leader is killed in the Middletown gamma bomb explosion, leaving Omnibus to take on the Leader’s mantle. In one Avengers movie, the Hulk could be Rick Jones while Bruce Banner stays in Gamma Base, searching for this new Hulk …

There is so much story to be told with the Hulk, and so much of it builds on the psychology of the man, his temper and impatient nature, his scientific genius, his fears of intimacy, his guilt, his dual identity and how he hides among and interacts with humans, about the question which one really is the man and which the monster… it would be a shame to not tell any of this in favour of three movies that could as well be done with another character.

Do I think this is how a Hulk TV series will turn out? I don’t dare to hope. But if it doesn’t, maybe these stories could be told in a ‘from the gallery’ fashion with a spin-off character. She-Hulk? Doctor Samson? We could learn about the Hulk from the distance: A force of nature that happens occasionally. A a friend or scientist who chases after him and halfway through the pilot gets exposed to something similar. Investigating the past of the Hulks might lead to a cure. Or it might lead to another Hulk.

Thinking about it, I think I’d love a female Doctor Samson/She-Hulk hybrid. The green long hair in a ponytail would make for a striking visual, and occasionally she could turn into the monster. It would always be a tightrope walk: How much superpower can she use before she loses control and becomes the monster?

But hey, what do you think?

Mapping Strings to Selectors

MappingStringsToSelectorsSketchBack in the old days of Carbon, when you wanted to handle a button press, you set up a command ID on your button, which was a simple integer, and then implemented a central command-handling function on your window that received the command ID and used a big switch statement to dispatch it to the right action.

In Cocoa, thanks to message sending and target/action, we don’t have this issue anymore. Each button knows the message to send and the object to send it to, and just triggers the action directly. No gigantic switch statement.

However, we still have a similar issue in key-value observing: When you call addObserver:forKeyPath:options:context, all key-value-observing notifications go through the one bottleneck: observeValueForKeyPath:ofObject:change:context:. So, to detect which property was changed, you have to chain several if statements together and check whether the key path is the one you registered for (and check the ‘context’ parameter so you’re sure this is not just a KVO notification your superclass or subclass requested), and then dispatch it to a method that actually reacts to it.

It would be much nicer if Apple just called a method that already contained the name of the key-value-path, wouldn’t it? E.g. if the key-path you are observing is passwordField.text, why doesn’t it call observerValueOfPasswordField_TextOfObject:change:context:?

But there is a common Cocoa coding pattern that can help us with this: Mapping strings to selectors. The centerpiece of this method is the NSSelectorFromString function. So imagine you just implemented observeValueForKeyPath:ofObject:change:context: like this:

-(void) observeValueForKeyPath: (NSString*)keyPath ofObject: (id)observedObject change: (NSDictionary*)changeInfo context: (void*)context
{
    NSString *sanitizedKeyPath = [keyPath stringByReplacingOccurrencesOfString: @"." withString: @"_"];
    NSString *selName = [NSString stringWithFormat: @"observeValueOf%@OfObject:change:context:", sanitizedKeyPath];
    SEL      action = NSSelectorFromString(selName);
    if( [self respondsToSelector: action] )
    {
        NSInvocation * inv = [NSInvocation invocationWithMethodSignature: [self methodSignatureForSelector: action]];
        [inv setTarget: self]; // Argument 0
        [inv setSelector: action]; // Argument 1
        [inv setArgument: &observedObject atIndex: 2];
        [inv setArgument: &changeInfo atIndex: 3];
        [inv setArgument: &context atIndex: 4];
        [inv invoke]
    }
    else
        [super observeValueForKeyPath: keyPath ofObject: observedObject change: changeInfo context: context];
}

We build a string that includes the name of the key-path, turn it into an actual selector, and then use -performSelector:withObject:, or in more complex cases like this one NSInvocation, to actually call it on ourselves.

For cases that have no clear mapping like this, you can always maintain an NSMutableDictionary where the key is whatever string your input is and the value the selector name for your output, and then use that to translate between the two. When you make whatever call equivalent to addObserver: you have in that case, it would add an entry to the dictionary. That’s probably how NSNotificationCenter does it internally.

Update:
As Peter Hosey pointed out, another good use case for this pattern is -validateMenuItem: where one could turn the menu item’s action into a string and concatenate that with ‘validate’.

Five Minutes to Twelve

CapaldiRoughSketch

The eleventh hour is close to its end, and tomorrow evening we will find out who will take over the part of Doctor Who from Matt Smith as the twelfth Doctor. Peter Capaldi is being handled as the prime candidate by the press.

While I think we’d be lucky to get an actor as amazing as Peter Capaldi (who Whovians have seen briefly as a Roman senator in The Fires of Pompeii) for the role, like in recent years, fans are speculating and arguing other possibilities. Among the most heated arguments is whether it isn’t time for the Doctor to represent the minorities of society.

“But the Doctor has always been …

… William Hartnell.” That was what anyone before 1966 would have said. When Doctor Who was originally conceived, it was a show about The Doctor, an alien grandfather that solved problems in time and space. Regeneration didn’t exist. It wasn’t until Hartnell asked to be let go from this job, that the show reinvented itself. The character of The Doctor changed.

Change has been at the core of the character from the beginning. Every couple of years, the show reinvented itself. The Doctor became older, younger, funnier, darker. One Doctor was like James Bond, with a gadget-filled car, another the weird uncle, yet another was rude. Whatever the current times needed, the Doctor could regenerate and become it.

So when people come up with arguments like “The Doctor has always been a man” or “The Doctor has always been white”, I can’t help but think these people have forgotten the central concept of Doctor Who.

Not that this is new in any way. Every time there is a regeneration, people are frightened of the new Doctor, and wistful for the days of the previous Doctor. Everyone is sad the Doctor they’ve become so used to, that they’ve grown to love in the past years is gone, and everyone is frightened of and disappointed by the few seconds they’ve seen of the new one.

I’ve been watching The Doctor since the mid-80s, beginning with re-runss of Tom Baker, Sylvester McCoy, Eccleston, then circling back to see some of the older Doctors while continuing with Tennant and Smith. And it happens to me again and again every time. I’m usually down to having to wait for the end of the first episode (or in the case of Matt Smith, the first trailer), but after 12 Doctors I still don’t get over a change in Doctors instantaneously.

Precedence

Even ignoring this traditional resistance to change, the authors have been slowly softening us up for a different Doctor.

Way, way back in the Tom Baker years, we saw Romana, a Time Lady from the same race as the Doctor, go through various forms, including weird aliens. Surely, if a Time Lord’s body can become a completely different species, surely a relatively simple thing like changing gender (something that is apparently decided early on during pregnancy, but before that all genders are essentially the same), or changing skin colour is not impossible for a Time Lord.

Similarly, some people complain that the Doctor so far has only been attracted to females, so is obviously male. But has he? The old series had a Doctor that was more a grandfather or an uncle to his companions, sometimes even having companions that were equal partners, but no real love affairs. The first time we see a hint at the Doctor being attracted to anyone is the 1996 Paul McGann TV movie, where the 8th Doctor (scandalously, for the Whovians of the time!) kissed his companion Grace Holloway. This then carried into the TV series nearly a decade later, but even there, the Doctor kissed the companions for non-romantic reasons: To save Rose’s life, to get trace onto Martha to use her as a distraction.

The first time the Doctor actually romantically kisses a woman (excepting cases where someone else initiates the kiss, like Amy forcing herself on him in Season 5) wasn’t until he kisses River in Season 7 of the new series. Actually the first kiss that could be construed as romantic and voluntary we see after Grace Holloway is the Doctor kissing Jack Harkness in Season 1.

So, there is surprisingly little onscreen precedence for the Doctor even being attracted to women, even if I personally believe he loved Cameca, Rose, Sarah Jane Smith and Madame De Pompadour, there is remarkably little confirmed onscreen. Especially Russell T. Davies’ Doctor was so warm and touchy-feely with all his friends, it’s hard to tell where that warmness ends and romance starts.

Apart from that, if you insist on the Doctor being romantic with his companions as the new series has him, you also have to accept the signs the writers put elsewhere: Like the Corsair, the Time Lord in Neil Gaiman’s first episode, where the Doctor casually mentions that she sometimes was a he and vice versa. Who says the Doctor couldn’t be a female attracted to the same sex in one of the incarnations?

What am I saying?

The Doctor has changed for years, and will be changing again. We humans are creatures of habit, and when we find something we like, we want to have it as long as we can, and we’re wary of change. It’s natural, but it’s something we actively have to work against. Just like the 11th Doctor, a Doctor who is Indian, a Doctor who is female, a Doctor who is alien will be new, and different.

Peter Capaldi? Lara Pulver? Colin Salmon? A complete unknown that manages to amaze us with a new interpretation? It doesn’t matter. Like every Doctor before, whoever, whatever the next Doctor will be, it will be different, and … fantastic.