BNR Day 3: NSLog(@"Oh Boy");
After two days on Objective-C, under the mentorship of Step Christopher, I'm feeling confident it's going to be a good week. It's always possible to criticize the design of a language, but overall, learning it is about just wrapping your head around a new set of words and relating it back to what you already know. I am confident life under the hood with iOS will be pleasant most of the time, but it's easy to imagine things getting out of hand with Objective-C in ways I've yet to find in other languages.
Ultimately, Objective-C has to solve the same handful of problems that other object-oriented language, building a machine with the same capabilities, just different components. Breaking down the parlance a bit, I arrived at this mapping of high-level features between C++, C#, and Objective-C:
|Class||Class||Class (@Interface + @Implementation)|
|Abstract Class + Multiple Inheritance||Interface||Protocol|
|Function Object (Functer)||Lambda (Delegates if you don't need variable closure)||Block|
Of course, the mapping isn't strictly one-to-one. In particular, the C++ technique for inheriting a set of abstract classes to fulfill a behavior contract is more akin to a design pattern. Both C# and Objective-C allow only single-inheritance plus conforming to a contract, making their implementations more of a language feature rather than programmer convention.
By far the thing I had the most sudden programmer fight-or-flight reaction to today was the Block syntax in Objective-C. True to the theme of the language, the syntax is very explicit, but also very chaotic when trying to read. For an example, try this article on Blocks from Big Nerd Ranch, I'll spare you an out-of-context sample here; I've already betrayed my bias.
Unlike in the class method declaration, this does follow a more C-like function syntax. The class method looks like it is a series of C-style casts wrapping an identifier, with colons helping delimit arguments. As a newcomer, the more C-like Block syntax certainly helps me learn, but at first blush it seems inconsistent with their established syntax for their other form of dynamic language function.
Additionally, this is the first time I've encountered closure being implemented in a language with manual memory management, which leaves me awestruck by the possible pitfalls it opens. Not only can you wrap up a read-only variable in a closure, they also give you facility for your blocks to opt-in on writing to variables. This means the ball of chaotic characters on the screen, ultimately living in a single variable, is dynamic behavior AND its own graph of objects in memory that needs managed. As a neophyte, it's reignited the paranoia I once only reserved for pointers-to-pointers-to-pointers in C++.