BNR Day 2: Genres of Code & Objective-C
The first two days of class at the Big Nerd Ranch are centering around teaching the Objective-C language itself, using the curriculum captured in their book on Objective-C Programming. Today was an overview of the C language, with an initial dive into the object-oriented extensions of the language. Even with a background in OO languages, I was a little taken aback by the syntax. After a day of exercises and guidance from our instructor Step Christopher, I wasn’t feeling so much like a hair metal band at a polka festival.
The stand out issue with Objective-C when first reading about it was the syntax for calling class and instance methods; it was all of these square brackets [[[wrapping names] in:incoherent] patterns]. Having grown up on C++, then transitioning to C# in my current job, I had a pretty fixed concept on how behavior belonging to objects should be called. For instance methods, something like:
objectName->methodName(arg1, arg2); // C++, w/ pointer
objectName.methodName(arg1, arg2); // C# and C++
Or for class methods, something like:
ClassName::staticMethodName(arg1, arg2); // C++
ClassName.staticMethodName(arg1, arg2); // C#
[objectName methodName] // Instance Method
[objectName methodName: arg1 arg2Id:arg2] // Instance with Arguments
[ClassName methodName] // Class Method
[ClassName methodName: arg1 arg2Id: arg2] // Class with Arguments
Losing my parentheses is quite a shock, magnified by having to know the identifiers of the receiving method’s arguments, it made a lot of the Apple Developer Doc examples pretty opaque at first. The key about the square bracket syntax is understanding that they are a core feature of dynamic object behavior in Objective-C, for both polymorphism and duck-typing-like behavior. Any object or class can be passed in on the left, meaning the method call (or “message”) is not tied to the type of the receiver at compile-time and is entirely runtime-dependent. Beyond just virtual methods in C++ & Co, this means disparate objects of disparate classes could stand-in for each other if they simply have matching method prototypes.
The other oddity is the arguments to the method. Arguments come after the method name, separated by a colon. The first argument to any function can be received implicitly, with subsequent arguments received in the order they are declared by the implementing function and marked by the names of the identifiers. It’s kind of like if every method in .Net required you to use the “:=” operator (which normally enables out-of-order argument passing) for every argument, except the first one, and it hard to be in the order declared by the receiver.
The recurring theme in Objective-C of “same idea, completely different implementation” looks like it will be following tomorrow. The concepts of classes are pretty straightforward the same, but as a practicing C# programmer, the words Interface, Protocol, and Extension are about to take on new meanings.
When I started off in college, I thought I was learning “programming”, much like how when playing trumpet I thought I was learning “music”. That is until I realized that I needed to know “classical music” and “jazz music”, with a large cross-over of shared techniques, but many details in each genre that define it as an art of its own to master. The more I branch out in computer languages, the more I realize I was trained on “C-based, Simula-Influenced, statically typed, statically scoped, object-oriented programming”; with perhaps a lacking in breadth. Sometimes you hear music so different, you wonder if you were deaf before hearing that new melody.