Under the Bridge

So chances are that you’ve never delved into the Objective-C runtime too deeply … and even better that you can’t imagine any particularly good reason you’d want to. But since we here Under The Bridge suffer from terminally insatiable curiosity, whenever we hear of something like that off we go. We’ll skip over the gory details, but there’s some interesting suggestions for useful things to do,

1. Automatic ivar/method searches. Apple’s Key-Value Coding does this kind of thing already: you give it a name, and it looks up a method or ivar based on that name and does some stuff with it. You can do that kind of thing yourself, in case you need to look up an ivar based on a name or something of the sort.
2. Automatically register/invoke subclasses. Using objc_getClassList you can get a list of all classes currently known to the runtime, and by tracing out the class hierarchy, you can identify which ones subclass a given class. This can let you write subclasses to handle specialized data formats or other such situations and let the superclass look them up without having to tediously register every subclass manually.
3. Automatically call a method on every class. This can be useful for custom unit testing frameworks and the like. Similar to #2, but look for a method being implemented rather than a particular class hierarchy.
4. Override methods at runtime. The runtime provides a complete set of tools for re-pointing methods to custom implementations so that you can change what classes do without touching their source code.
5. Automatically deallocate synthesized properties.  The @synthesize keyword is handy for making the compiler generate setters/getters but it still forces you to write cleanup code in -dealloc. By reading meta-information about the class’s properties, you can write code that will go through and clean up all synthesized properties automatically instead of having to write code for each case.
6. Bridging. By dynamically generating classes at runtime, and by looking up the necessary properties on demand, you can create a bridge between Objective-C and another (sufficiently dynamic) language.

#5 is particularly interesting, as  it certainly would be convenient if that long list of IBOutlets you just added would clean themselves up automatically, wouldn’t it? And in the comments, there is a fellow who’s done just that:

Here’s a category of NSObject that can simplify a dealloc method. It adds the method setEveryObjCObjectPropertyToNil that sets every property of the receiver to nil. (Properties that are readonly or not an Objective-C object are ignored.) This frees the underlying object, if the property is declared copy or retain; and it does no harm if it was declared assign.

Nifty, indeed. Even if you’re quite sure you’re conscientious enough to have no need of relying on this in your own code, the implementation is still worth taking a look at to figure out just how the magic happens when you want to do introspective stuff like this!

h/t: iPhoneKicks!