Cocoa Bindings

Brent Simmons just started using Cocoa Bindings:

It was, I confess, a reaction to that terrible feeling you get when you’re faced with creating yet another NSTableView data source and delegate. I just couldn’t face another objectValueForTableColumn:blah:blah:whatever:.

and he likes them. I actually had the opposite reaction a few days ago. I was excited to use bindings, as I had already made the decision that the application would require Panther. I love the idea of bindings. And, indeed, bindings made it very easy to implement the basic functionality for the table. No datasource methods! No need to sort! Automatic updates! But the last 20% looked daunting. I needed typehead, editing and insertion validation that depended on objects outside of the row, control over when editing and deletion should be enabled, standard keyboard shortcuts that aren’t implemented by the framework, etc.

I started mapping out the subclasses I would need—you have to subclass to even know what the view objects are bound to—and how they would be hooked together, and decided that I could probably get it to do what I wanted to do, but that it just wasn’t worth it. There’s no sense in fighting the framework. Sure it’s kind of silly that I have to write -numberOfRowsInTableView: yet again, but it’s also the simplest method in my class so it’s not a big deal if the framework can’t handle it automatically.

Another case where I ended up not using bindings was in a pop-up menu that needed to be populated from an array, but that also needed a few extra menu items. Bindings don’t seem to have been designed to handle that.

This is not to say that I don’t like bindings or that I won’t use them. Like -takeStringValueFrom:, they make for a great demo, and sometimes they do exactly what you want (most likely for uneditable views). But they’re not as flexible as other means and are not always the right solution. As I write new code, I will keep looking for places where it looks like bindings will help, but I have no desire to convert my old code to use them. Aside from the extra work, I am convinced that in some cases it would make the code harder to understand and slower.

A final point: it’s not bindings or nothing. Developers can build their own helper objects that work with the standard datasource and delegate methods. These can provide some of the convenience of using bindings, but with easier customizability and more room to grow.