Cocoa Is My Girlfriend

After reading Fraser Speirs’ excellent write-up on his conversion over to git, I followed a few of the links to find a bash script to display your current git branch in the command prompt. Following yet another link from that post showed how to convert the bash script to zsh.

Here is my contribution to move that from the prompt to the right side of the screen.

1
2
3
4
5

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
function precmd() { RPS1="%~$(parse_git_branch)" }
export PS1='> '

Note that the last line just gives me a very short left hand prompt which I prefer.

Uploaded with plasq’s Skitch!

I was not born an Objective-C developer. I know that in some circles that is considered a mortal sin. Before learning Objective-C and Cocoa I had developed in a great number of languages dating back to the early 1980’s. I tell you this so that what you are about to read next is taken in the light that it was intended.

Take a look at the following lines of code:

- (void)doSomethingSpecial
{
	myVar.itsAttribute = 10;
	myOtherVar.itsAttribute = 20;
}

Now tell me, what is myVar and myOtherVar. Is it an object or a struct? Can’t tell from that piece of code can you. That is half of my argument against dot syntax in Objective-C. It makes the meaning of your code unclear. Objective-C is known for its self documenting nature. Dot Syntax removes that.

Next, lets take a look at another piece of example code:

-(BOOL)myCompliatedMethod
{
	MyObject *object = [[MyObject alloc] init];
	object.attribute1 = 10;
	object.attribute2 = 20;
	OtherObject *nextObject = [[OtherObject alloc] init];
	[nextObject doSomethingAmazingWith:object];
	if (nextObject.result > 10) {
		[object doSomethingElse];
		return NO;
	}
	return YES;
}

Yes, this is clearly contrived code. However, hopefully, its meaning is clear. dot syntax breaks up the flow of the code. Code should be elegant. It should be graceful and beautiful to look at. This is ugly, nasty code that you want to fold as fast as possible so that you can stop looking at it. The message passing lines are completely at odds with the dot syntax lines. The difference is striking and distracting.

When we write code, we care about its formatting. We care that the code is properly indented and that the indentation is consistent. We should care equally as much about its consistency of style and design. Switching from message passing over to dot syntax and back is not consistent.

Now lets compare this against keeping the entire method within message passing:

-(BOOL)myCompliatedMethod
{
	MyObject *object = [[MyObject alloc] init];
	[object setAttribute1:10];
	[object setAttribute2:20];
	OtherObject *nextObject = [[OtherObject alloc] init];
	[nextObject doSomethingAmazingWith:object];
	if ([nextObject result] > 10) {
		[object doSomethingElse];
		return NO;
	}
	return YES;
}

There is now a consistency of form and style. The code flows more smoothly and is not as jarring.

Dispelling some myths

I want to dispel a couple of myths about dot syntax in Objective-C while I am on the subject.

1. Dot syntax is not faster than message passing. It is syntactic sugar that is translated to normal message passing.
2. Using dot syntax to set an attribute to nil is not a more efficient way to release an object. It is less lines of code but just as heavy as [object setAttribute:nil].
3. Using dot syntax will not directly access the attribute on an object. While this is true in some languages, the actual call path for an Objective-C dot syntax accessor is:¹
   • Resolve the accessor selector from the call
   • The accessor method, if that does not exist
   • The attribute itself, if that does not exist
   • The unknownValueForKey: method is called last.

Why did Apple add it?

I have my own theories on why this nastiness was added to the language. It could be due to all of the windows hacks coming over to OS X and a desire to make them feel a little more comfortable.

It could be that a battle rages between the Carbon developer and the Cocoa developers and this was a concession to the Carbon developers since Carbon is going away.

It could be that while adding properties (a most useful feature of Objective-C 2.0), the developers decided “why not” and threw them in there.

We may never know the real reason behind adding these to the language. However it is clear that they are here to stay and I mourn their coming. They are a confusing addition to the language and cause developers new to our platform to bring bad habits with them.

Unfortunately they have made their way into Apple’s sample code as well as the language. This is truly unfortunate. As I have mentioned in the past, the sample code that Apple provides is not the best case solution; however many developers will think so. By adding dot syntax into these examples, it exacerbates the problem. New/young developers coming to the platform will see this dot syntax as the “right way” to do things and they will become a maintenance nightmare.

Maintainability

The last thoughts on this subject are with regard to maintainability. We often forget about this aspect when we are working by ourselves. However, maintainability is not just a factor when we hand off code to another developer, it is also a factor when we have to come back to our own code 6 months from now! I don’t know about you but when I look at code I wrote a year ago all I can think is: “That moron! What the HELL was he thinking!”

Since dot syntax is not as clear with regard to intent as message passing is, then we should avoid it for maintainability as well. Who wants to have to constant flip back to the header file while reviewing a piece of code to remember if we are talking to an object or a struct. Keep the intention clear, keep the code clear, and maintainability will follow.

Conclusion

In the end, it is a matter of preference. I hope that these topics have helped to show the negative effects of using dot syntax in Objective-C. It is purely syntactic sugar and adds nothing to the language. However, there are so many cons that I cannot suggest that anyone use it in any situation.

As you can probably imagine, we have been heads down coding for the past month. Can I tell you what I am working on? Nope and if you are in the community you can guess why.

However, here is a hint.

What does a deadline look like?

And my desk to go along with that link:

Uploaded with plasq’s Skitch!