For the third time now I am tackling Aaron Hillegass' "Cocoa Programming for Mac OS X." I've finally reached the farthest point that I'd reached previously ("Bindings and NSController"), but this time I actually understand what's going on. Mostly.
I'm realizing something that I think the book glosses over: the AppKit framework -- the classes you use to communicate with the OS X GUI -- is quirky. Understanding what you're doing involves knowing all of the bizarre ways your code needs to interact with AppKit. For the methods in any particular class you have to know what it returns, what it retains, what happens if you send it nil...and you also need to know which methods it delegates to other objects...
I'm sure that for common classes this becomes second nature. But when I see inconsistencies in Hillegass' code, and he doesn't explain why they're there, a bit of research reveals that it's due to a class quirk...a quirk I wouldn't have known about if *I* were writing the code.
I was in a rage tonight, trying to figure out why he allocates memory for and initializes SOME objects, but not others. I think it's because some of these objects -- the ones you use often for temporary reasons, like NSString -- can allocate and initialize for themselves, since they're immutable and they'll be autoreleased as soon as the method ends anyway.
Speaking of releasing, I'm not even thinking about that yet. The knowledge that (as Hillegass basically says) some methods retain objects and some don't, and you just need to learn which does which, is not exactly heartening.
But I do have to say: wow, this is elegant. The way that all these objects lock together, sharing their duties in such a logical way, is a miracle of design. I love it!
Until I get stuck again...
No comments:
Post a Comment