Tag Archives: Programming

Adventures in Objective-C – Part 1

I’ve been trying to get my head around Objective-C and Mac/iPhone programming for the last month or so. At this point, I think I’ve got most of the major concepts down.

As an Object Oriented (OO) language, it bears a certain familial resemblance to Java, which I typically program in these days.

While I’m not going to say that Java is a “better” language, I do feel that parts of Objective-C are a capricious conglomeration of logic-unfriendly syntax.

It’s the implementation of these things that’s irritating. Obviously there’s a certain amount of familiarity and personal preference, but over this series of articles, I’ll highlight a few. I’ll start with a simple syntax example.

Generally in OO programming, you break things into programatic “objects”, which define the properties of an object and the actions that such an object could do.

In Java speak, these are properties and methods, in Objective-C they are properties and selectors. In Java you “call” a method, in Objective-C you “message” a selector. Same thing, different terminology. Clear as mud? Good, then let’s continue.

Typically, properties on an object are protected behind accessor method, such as “getXXXX” and “setXXXX” where XXXX is the property name. Sometimes these are called “getters and setters” – that’s in Java, of course, Objective-C calls them “accessors” and “mutators”. Objective-C also uses a slightly different convention. Mutators are still “setXXXX” but accessors are just “XXXX”, which can result in a little ambiguity as to whether you’re looking at the actual property variable or the accessor selector.

Java uses “dot-syntax” to refer to an object’s methods, so far example, if you have an object called “newton” and it has a method called “dropApple()”, you would access it like this:

newton.dropApple();

Objective-C uses square bracket syntax, so the same thing would be:

[newton dropApple];

…and if each one took a single parameter, they would look like this:

newton.dropApple(velocity);

vs

[newton dropApple:velocity];

It gets a little muddier when we move to two parameters.

In the example above, I’ve passed a variable called “velocity” which we’ll say is of object type “Speed”. Let’s add a second object type of “Height”, with an instance variable called “headHigh”

We would DECLARE the java method like this:

void dropApple(Speed incomingSpeed, Height incomingHeight) {

…. do stuff

}

and call it like this

newton.dropApple(velocity, headHigh);

Objective-C would be declared like this:

(void)dropApple:(Speed *)incomingSpeed dropHeight:(Height *)incomingHeight {

…. do stuff

}

and called like this:

[newton dropApple:velocity incomingHeight:headHigh];

Here’s my first irritant, Objective-C selectors use named parameters – which I like better than Java, but only on the second and subsequent parameters. The first is identified by the name of the selector. It’s just a mixed-bag inconsistency. I hate inconsistencies in my programming languages.

This same system also helps cause Objective-C messages to tend to be very long.

Java and Objective-C also share another trait, that being if a message/call returns an object, you can then, in turn message/call that object immediately without passing it through an unnecessary intermediary object variable.

Let’s say we’re somewhere inside an object that is running active code – like a program. I can always reference back to myself with the special keyword “self”, so if my program has a property of type Person, and a Person object has a property of type “phoneNumber” and a PhoneNumber has a method that returns a formatted representation of the number, we can get to that formatted string in java like this:

self.getPerson().getPhone().format();

Self being an object with a getPerson() accessor that returns a Person, which in turn has a getPhone() accessor which returns a Phone, which in turn has a format() method to return a pretty string. It’s not uncommon to see these things strung together 4 and 5 levels deep inside Java code, and it’s a bit difficult to read, but convenient, and sometimes a lot better than assigning each step to a new variable, like this:

Person aPerson = self.getPerson();

Phone aPhone = aPerson.getPhone();

String aString = aPhone.format();

How does Objective-C handle this? Like this:

[[[self person] phone] format];

Simpler, right? Yes and No. It’s irritating. Why? Because you have to know, in advance, how many layers deep you are going so that you can put the right number of square brackets on the left. If not, you have to come back later and add them, which really “breaks the stride” of typing. It may be less letters to type, but it takes longer to type.

Ah, but along comes Objective-C 2.0 with a “solution” to this: Dot-Syntax!

Oh, but it isn’t the same as Java’s dot-syntax. Objective-C’s dot-syntax only applies to properties, not selectors. (Actually, properties are selectors, you’re not seeing the actual variable, but these are special) That means you can do this:

self.person;

or

self.person.phone;

but not

self.person.phone.format;

instead it would be:

[self.person.phone format];

Why is this a problem? You don’t always know if something is a “property” or “selector”, and since the IDE (XCode in this case) helps fill this stuff in from it’s calculated list of available options, it promotes a certain natural “coding laziness” by letting the IDE do the work of remembering names for you.

So you start typing “self.pe…” and about that time it suggests “self.person”, so you hit the arrow and continue typing “.ph…” and it breaks in again and suggests .”phone” so you hit the arrow to accept and then you start “.format” and nothing happens, then you realize, “oh, it’s not a property”, so you go back and delete the period. That’s bad typing technique. And, then, of course, you have to go back to the beginning of the clause to add a “[” and the end of the line to add “]”

I know, I know. “Gripe, gripe, gripe, gripe”

Next time (probably) “Why there isn’t a consistent method for delegates, actions and ad hoc delegates”