Objective-C Dot Notation ~ Wed, 16 Jun 2010 19:13:35 +0000
A few weeks ago O'Reilly was having an eBook sale where you could buy any of their eBooks for $10. Seeing as I had just ordered an iPad, I decided to buy their Learning iPhone Programming book. The little bit I know about developing for the iPhone has come from reading (most of) Cocoa Programming for OS X and applying that knowledge with searching through the API documentation. So I figured it wouldn't hurt to read a book specifically dealing with iPhone programming. I'm four and a half chapters into the book, and, thus far, it is pretty good. I am learning some stuff I did not know about before. But there is something about the book that bothers me.
The author of Learning iPhone Programming uses a feature Apple introduced into their Objective-C 2.0 -- dot notation. I really wish Apple hadn't created this feature because it is just plain confusing. Joe Conway describes problems with the notation that I had not thought of, but I think it is confusing for a reason he didn't explicitly mention. Dot notation in Objective-C obscures objects. For example, chapter 5 covers building a table view application. There is a point in the code where a table cell's text label is set to a new string. The author uses this code:
cell.textLabel.text = @"Testing";
The pre-Objective-C 2.0 way of writing this is:
[ [cell textLabel] setText: @"Testing"];
Can you see the subtle difference? The UITableViewCell is composed of several objects, one of which is a UILabel. In order to change the text displayed in the table cell you have to change the text on the contained UILabel. So, you ask the cell object to give you a reference to it's textLabel object and then set the text property of that object. The dot notation doesn't really make that clear. Instead, it looks like you are accessing properties of a struct. With the bracket notation I think it is much clearer that multiple objects are being referenced, and which methods of those objects are being used.
For final example, let's look at some code that I found in a StackOverflow question:
LoginViewController *myLoginViewController = [[LoginViewController alloc] initWithNibName:@"LoginView" bundle:nil]; [[UIApplication sharedApplication].keyWindow addSubView:myLoginViewController.view]; [[UIApplication sharedApplication].keyWindow makeKeyAndVisible];
This guy is using both syntaxes at the same time! Written without dot notation, that code is:
LoginViewControler *myLoginViewController = [[LoginViewController alloc] initWithNibName:@"LoginView" bundle: nil]; UIWindow *keyWindow = [[UIApplication sharedApplication] keyWindow]; [keyWindow addSubView: [myLoginViewController view]]; [keyWindow makeKeyAndVisible];
One extra line and the code is much clearer. We can easily see that we are adding a new view, from the myLoginViewController object, to a UIWindow object, keyWindow.
You can decide for yourself which notation you like better, but I think you'll be better served with the traditional bracket notation. Especially if you want to contribute to any open source projects (e.g. Adium). Chances are pretty good that most people will be using bracket notation. And they're not going to like it if you start submitting patches with dot notation.
Update: Right after posting this article I came across a new StackOverflow question that further illuminates the problem with dot notation. Getter and setter methods have completely different names with dot notation (which can be seen in my first example).