A new version of class-dump is now available. This release includes several bug fixes and a few minor enhancements. It’s recommended for all users of Mac OS X 10.4 or later. You can download it from the links on the class-dump project page, and see a detailed summary of the changes.
My favorite new feature is the -f option. This lets you search for methods and display them in context, showing the class, category or protocol that contains the matching methods. Before this, I would just class-dump a framework and search for the method in the output. In classes with a lot of methods, though, I’d have to scroll up to see what class contained the method, and it was difficult to get a good picture of the results. Now you can just use the -f option and get a nice short summary. This is great for discovering what classes implement some bit of private API. For example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
The string is case sensitive and doesn’t support regular expressions. I just needed something simple, and it works quite well.
The -H option now generates protocol header files. These are named <protocol-name>-Protocol.h, which differs from the imports generated by the previous version. The extra dash in the name helps make them stand out against regular classes that end in Protocol, such as NSURLProtocol.
I’ve also added a –list-arches option that prints the architectures contained in the given file. I added this for my regression testing, so that I can dump all architectures that are available. Unlike lipo -info, it only lists the architecture names, which makes it easier to use in shell scripts.
I’ve added several fixes for files that use C++, so a bunch of old warnings should go away. This version of class-dump also recognizes Apple protected binaries, and won’t spew a bunch of garbage when you try to dump these files.
There are two big changes in the source code. First, I’ve implemented a visitor pattern for going through the Objective-C data to generate output. When I first implemented the -f option, I just copied the old generation code and added the pattern check. It was a quick and easy proof of concept, but it wasn’t maintainable. With the visitors most of the actual output is contained in one or two classes, instead of being spread out among many classes. I like it a lot.
The other change was converting the unit tests from ObjCUnit to OCUnit/SenTestKit. It makes sense to use OCUnit since it’s bundled with the developer tools, and ObjCUnit was crashing, so it was just as easy to switch. After converting the unit tests it was apparent that the two frameworks were practically identical in usage. Just import a different header file, subclass from a different test case class, and use slightly different asserts. My main reason for picking ObjCUnit originally was that it was easier to control the order of the unit tests, but I’ve managed to get that working with OCUnit.
The next version will be 10.5 only so that I can start using some of the new features that are available. I think I can add support for @rpath, and supporting 64-bit files is on my list of things to do.
As always, you can send bug reports to me at nygard at gmail.com