Ok not so much a small talk, but more a ramble with an objective. (wow, geek humor is really bad).

I’ve had the fortunate ability to spend the past 2 weeks or so getting ramped up on all things iOS and Objective-C for an internal project my company is working on. As a guy who has historically programmed in C-style languages and environments (.NET, Java, C/C++, and JavaScript), I thought this language would be pretty easy to pick up.  I was both right and wrong.

Of course, the core syntax of Objective-C IS almost exactly the same as C, which is great. For me to read through the code and understand which method was calling which other method and why and how, to follow the pointers and references, and the basic structure and syntax were all easy.  Then came the hard part.  Understanding both the Smalltalk-inspired messaging features that are grafted into C, as well as the modifications NeXTSTEP and Apple had taken with the language over the years.  This required a lot of reading.

The first thing for me was to identify all of the interop types that I was starting to see in examples all over the place. This was very reminiscent of all of the coding I had done with C++/CLI where native C types could stand alongside .NET managed types (Well… sort of. I mean, that was the theory with C++/CLI even if that didn’t really all that well. You know what? Let’s never mention C++/CLI ever again). So I understood of course Apple had their own wrapped object framework, like most languages that abstract from native code – NSObject being the base to most things – so I started here.  As a side note, while I was aware that the “NS” in Apple’s core frameworks stood for NeXTSTEP/Sun, I DID NOT realize that the NS “prefix” on all of their objects actually served a greater purpose.  Objective-C does not support namespaces. At all. Yes, you read that correctly. There is no concept of namespaces in Obj-C.  It’s probably one of the top more easily referenced complaints of experienced developers that switch to using Obj-C.  Apple’s hacky solution?  Prefix all of your classes in a library or project with an all-caps, two or three (or more) character prefix. So instead of codemouse.myproject.data you do something like “CMMPD” as a prefix on every file and class.

namespace CodeMouse.MyProject.Data
{
    public class DataConnector
    {
        //yay namespaces.
    }
}

CMMPDDataConnector* dataConnector;
//This CMMPD prefix everywhere is as good as it gets in Obj-C land. Man I miss namespaces.

YES, in theory, you can most certainly have code collisions this way with third-partly libraries. Though it seems in actual practice, this is rare – and with the rise of package managers like CocoaPods, which functions for OS X similarly to how nuget package manager functions for Visual Studio), this seems even less likely.

OK back to our funky NSObject.  I’ll tell you when things finally started to click for me. So I started seeing references to nil everywhere. Nil nil nil. I was like OK, is this like NULL?  Well…. no.  Nil, like all message-enabled objects in Obj-C is… uh, well… It’s message-able.  Huh? OK. Let me explain. If I had an object in C or C++ or C# or Java that was NULL, the value itself was NULL and I tried to call upon properties or methods of that object, I would universally get a Null Reference exception.  This is why there is always so much checking for obj != null in all this code, because without that you’d get a ton of runtime exceptions if something slipped through the cracks.

MyObject myObject = null;

//poke the bee hive with a stick
var result = myObject.DoSomething(); //I'M NOT OK WITH THIS
//System.NullReferenceException barfs on your screen

MyObject* myObject = nil;
NSString* result;

//come at me bro
result = [myObject doSomething]; //I ain't even mad
//result = nil;

So Obj-C objects don’t have the classic Null Reference issue. Since nil is message-able (is that a word? it is now), it’s perfectly allowed to respond to anything that you send to it. It wont DO what is requested of course, but it will respond to your message. Meaning, if I call a property on a nil object, I will not receive a runtime exception, I will get nil.  This was a crazy concept for me to grasp (and kind of exciting actually) and helped to set the stage for understanding the entire Messaging paradigm.  I am used to thinking of methods and returns, but that is not quite correct in how Obj-C works.  I found this blog post explains this (and the potential pitfalls of this) fairly well. The most often way you will see this taken advantage of in Obj-C is through a large pile of nested method calls (without fear of it breaking the compiler somewhere along the way).  Since Obj-C is far from the least verbose programming language, I am a fan.

There were other things to also figure out. OK, so there is no “this”, Apple decided to call it “self” – probably to differentiate from C (OK, FINE – I’ll take a [self]ie rather than this or that). Update: as was pointed out to me via Reddit, “self” was a core designation of Smalltalk and Apple explicitly borrowed this same concept. And yes, C itself DOES NOT have a concept of “this” (only C++).

Then I stumbled upon “id”.  What the heck is “id”?  I have used C# very heavily over recent years and tried to equate “id” to a variety of things over in .NET-land. Was it like “object”? No… Apple had a generic base object implementation called, NSObject.  Ok… So, was it like “var”? No, “var” is merely implicit typing and still gets checked at compilation. OK so… “dynamic”?  Yes. Well, sort of.  TL;DR;, I’ve decided it’s equal to a hybrid of “dynamic” and “IntPtr” because “dynamic” of course relies on the DLR (which Obj-C has no direct comparison) learned that since Smalltalk was originally designed to have every object potentially be dynamic and messagable, this is an expected and core behavior in the entire framework. So basically “id” is just a pointer to an object that is not static-type checked at compilation. Which of course means it can fail miserably at runtime if you screw it up.  Still, it was good to realize that Obj-C had this concept (inherited directly from Smalltalk), and I have begun implementing it heavily where appropriate, particularly when I always know the expected type that is returned.

What else… Well, Enums are basically, enums (more or less). Structs are basically structs.  The “@” symbol in front of EVERY SINGLE Obj-C NSString really bugs me, but Apple insists that again, its to differentiate between its own wrapped strings and native C strings.

String myString = "this is a perfectly reasonable string";

NSString* myString = @"this is a perfectly reasonable string";
NSString* myString = "i forgot my @ symbol and i hate everyone, especially YOU, clang compiler";

The method parameter list conventions really threw me.  Parameters are separated by colons than commas (fine), and they are ordered parameters (not named). OK.  But, they have “optional” prefix names that you can specify to help identify which parameter is which.  The names are ignored by the compiler so they can be anything, but are really there for the developer’s sake. OK.  That’s cool. BUT… The first parameter in every method signature is not allowed to have a prefix name. Huh?  Yea well…. Apple things it’s best that the method itself should be suffixed with a relevant lead-in to the “main parameter” you want to pass.

//here's my method signature
public void ModifyThisAndThat(string thisString, string thatString) { }

//here's me calling this method
ModifyThisAndThat("this", "that");

//here's my method signature
- (void)modifyThisAndThat:(NSString* thisString) thatString:(NSString* thatString) { }

//here's me messaging this method
[modifyThisAndThat:@"this" thatString:@"that"];

Ugh. Ya know, I can see a lot of value in their structuring here – it somewhat forces you to really think about the params you are passing. Ideally they inadvertently steer you towards passing only ONE parameter that the method expects, and then maybe an array or object of options – which – is better programming practice in general. But I don’t understand why they forcefully pushed these standards when they could have made them optional.

Lastly, I was happy to figure out that Obj-C support anonymous methods (yay) via something they refer to as blocks.  Blocks can be directly translated to C#’s lambdas as anonymous functions. With the advent of LINQ and C#’s ever-increasing arsenal of functional programming techniques, I have grown very accustomed to using anon functions inline all the time. Luckily, this is easily supported in Obj-C too.

//oversimplified LINQ iteration with lambdas
myStringCollection.ForEach(x =>
{
    if (x == "these are the droids i am looking for.")
        Console.WriteLine("i found them.");
});

//oversimplified FastEnumeration iteration with blocks
[myStringCollection enumerateObjectsUsingBlock: ^(id x, NSUInteger idx, BOOL *stop) {
    if ([x isEqual: @"these are the droids i am looking for."])
        NSLog(@"i found them.");
}];

So… There’s still plenty more that I need to figure out. And don’t even get me started on learning Cocoa, Quartz, and all the other frameworks. I miss data binding and MVVM and I’m trying to embrace Notifications and MVC. XCode was one of the strangest IDEs I have ever had to learn (and still continues to be). iOS certificates and deployments for device testing is probably about as complex with how you would do this with Windows Phone, so that was no big deal. I can say overall I am happy to have learned another language. Objective-C itself is pretty great. Some apple-centric things and practices I may have some disagreements with, but I can live with that. I look forward to Obj-C 3.0 being release sometime in the next few years to address namespacing and to add some additional modern elements to the language.  We’ll see what’s next.

 

– b