Log in

No account? Create an account
Apr. 18th, 2012 @ 11:26 pm The Objective See
About this Entry
Spiketail Hatchling
We're not talking about the Holy See, but rather the objective one.

Now, having some experience with Objective C, I can tell you that it's a kinda-different sort of beast-- both similar and different to Java and C++. Like C++, Obj-C is a superset of the C language. You can theoretically write a C program in either C++ or Objective C. The problem is one I've addressed before.

I'm delving deeper this time. Objective C is minimalist on its own. It's a cool toy, but it's real use comes with an Apple operating system: iOS for iPhone/iPad or OSX. For these, there's a standard library with lots of things like hash maps and mutable strings... sort of like Java or C++'s standard library.

Here's where shit hits the fan. C has malloc and free for memory management of your heap. It's pretty gosh-darn easy. C++ has new and delete. Java has new and a garbage collector. Objective C (with this standard library) has some alloc/init/retain/release/autorelease/dealloc nonsense where you have to worry about the retain count of your object. Things have gotten easier with ARC (automatic retain-counting), but that's only in new versions.

So, in C++ or Java, you say "ObjectX varName = new ObjectX();" and you've got your new object. In C++, it must be deleted ("delete varName;"), and in Java, it'll automagically know when nothing's calling upon your variable and quietly put it down when you're not looking. With Cocoa, when you make the object ("ObjectX *varName = [[ObjectX alloc] init];") it sets its retain count to 1. If you want to increment its retain count, you call the retain method-- I mean send the retain message-- "[varName retain];". When you release it, you replace 'retain' with 'release', and it'll call some internal 'dealloc' method. Message. Damn it.

That's the other thing about objective C is its nomenclature. In Java and C++, an object is defined by a class. It's abstracted by an interface. Classes contain methods. In objective C, classes are defined by interfaces which are abstracted by protocols. Classes contain message definitions.

This sucks that, like everything else Apple uses, it's just trivially different from the rest of the world.

On the plus side, while everybody else tries to bolt object-oriented-ness into C and make it resemble the C-syntax, Objective-C's object-stuff stands out in a Smalltalk-ian way. All the C nuts and bolts for conditionals, loops, and things still work. The C standard library remains untouched (unlike in C++, where include files gain a 'c' in front of them), and everything else is smashed on top.

In fact, if you threw together a Obj-C program and edited out any lines containing brackets (that aren't arrays) and @s, then you'd have a C program. (Well, also a couple of preprocessor directives, but I'll give 'em that). So, it's a quirky mish-mash of things. In fact, the language alone is interesting enough to play with, but not different enough to warrant serious attention. The addition of Cocoa makes it bothersome and unpredictable.

Here's an example. An object can be 'nil' (read NULL). Passing a message (calling a method) of nil is allowed. It does nothing. In Java or C++, this would cause some problems (since NULL doesn't have any methods). So, in this case, Obj-C is on the ball. Passing bogus / nonexistent messages doesn't cause any harm. Here's where Cocoa comes in, though. Passing messages to a deallocated (released or whatever) object results in a crash. Not an exception, mind you, the program crashes. (It's still C, remember?)

So, that's that. I'd like to say that I really like it, or I really hate it... but I don't. It's yet another C-ish language. It's different in the way that a MacBook is different from a Linux notebook... that special, superficial, pretentious-feeling sort of way.

Lecture adjourned.