I fixed a rather nasty bug today in AspectObjectiveC. One particular unit test would crash with EXC_BAD_ACCESS every time. After learning far more about registers and ABIs than I ever wanted to know (thanks, Greg Parker), it dawned on me that performSelector: was corrupting memory. It was particularly hard to track down because the crash would happen a couple of lines after the call to performSelector:, when the corrupted memory was actually accessed.

I’ve never had a problem with performSelector: before, but this time I was using it a little differently. The return value of the selector was an NSRect.

Now for the gory explanation.

(more…)

Here’s a quick video about AspectObjectiveC, and what it can do. The code is available from github. I should also mention that AspectObjectiveC isn’t ready for release just yet.

I’ve started a new side project called AspectObjectiveC on github. It’s a little aspect-oriented programming framework for objective-c.

In a nutshell, it allows you to run arbitrary code before, after, or instead of any method at runtime. You can modify arguments before they enter the method, modify the return value of the method, or completely replace the method’s implementation without touching the class’ source code. This includes classes that you don’t have the source code for (e.g. other frameworks). It’s released under the MIT license, even though it doesn’t mention it anywhere yet.

It’s still rough, but it’s working (on my machine ). If you want to try it out then build the framework target and whack it into an app as a private framework. It’s got no documentation yet, but the public headers only expose one protocol (AOCAdvice) and one class (AOCAspectManager) with two methods, so it’s pretty intuitive. You can check the unit tests for example usage too.

If you want to contribute code, that’d be great. If you want to test it out on platforms other than OSX >= 10.5, i386 with gcc, that would also be great. Feel free to shoot me an email about it.

This post is the result of investigation into a stackoverflow.com question of mine.

So, you’ve created a spiffy NSView of your own, and have decided to make it compatible with bindings. Great! So you go and read the documentation, and you look at mmalc’s GraphicsBindings example. You override bind:toObject:withKeyPath:options: and everything works. But wait! Why isn’t the NSWindowController ever being deallocated anymore?

Now you’ve got a nasty retain cycle on your hands. You do a little research and discover that not only do other people have the same problem, but even Apple’s bindings used to have it a few years ago. How did Apple fix the problem? With the magic, undocumented class NSAutounbinder, which nobody seems to know much about.

Other people will tell you that you don’t need to override bind:toObject:withKeyPath:options: and that bindings work automatically. This is only a half truth. NSObject does provide an implementation of bind:toObject:withKeyPath:options:, but it only half works. Using the default NSObject implementation, changes in the model will update the view, but the reverse is not true. When the bound property of the view changes, nothing happens to the model.

So, what is a Cocoa developer to do? I’ll explain how to implement your own bindings that work exactly like Apple’s, with no retain cycles. I haven’t found this solution anywhere else, so as far as I know, I’m the discoverer. I feel so special. It has been mentioned before at least once. The solution is hard to find, though.

(more…)