Dot notation vs. message notation for declared properties
Do not use dot for behavior. Use dot to access or set attribute like stuff, typically attributes declared as properties.
x = foo.name; // good
foo.age = 42; // good
y = x.retain; // bad
k.release; // compiler should warn, but some don't. Oops.
v.lockFocusIfCanDraw; /// ooh... no. bad bad bad
For folks new to Objective-C, I would recommend not using the dot for anything but stuff declared as @property. Once you have a feel for the language, do what feels right.
For example, I find the following perfectly natural:
k = anArray.count;
for (NSView *v in myView.subviews) { ... };
You can expect that the clang static analyzer will grow the ability to allow you to check that the dot is being used only for certain patterns or not for certain other patterns.
Let me start off by saying that I started programming in Visual/Real Basic, then moved on to Java, so I'm fairly used to dot syntax. However, when I finally moved to Objective-C and got used to brackets, then saw the introduction of Objective-C 2.0 and its dot syntax, I realized that I really don't like it. (for other languages it's fine, because that's how they roll).
I have three main beefs with dot syntax in Objective-C:
Beef #1: It makes it unclear why you might be getting errors. For example, if I have the line:
something.frame.origin.x = 42;
Then I'll get a compiler error, because something is an object, and you can't use structs of an object as the lvalue of an expression. However, if I have:
something.frame.origin.x = 42;
Then this compiles just fine, because something is a struct itself that has an NSRect member, and I can use it as an lvalue.
If I were adopting this code, I would need to spend some time trying to figure out what something is. Is it a struct? Is it an object? However, when we use the bracket syntax, it's much clearer:
[something setFrame:newFrame];
In this case, there is absolutely no ambiguity if something is an object or not. The introduction of ambiguity is my beef #1.
Beef #2: In C, dot syntax is used to access members of structs, not call methods. Programmers can override the setFoo: and foo methods of an objects, yet still access them via something.foo. In my mind, when I see expressions using dot syntax, I'm expecting them to be a simple assignation into an ivar. This is not always the case. Consider a controller object that mediates an array and a tableview. If I call myController.contentArray = newArray;, I would expect it to be replacing the old array with the new array. However, the original programmer might have overridden setContentArray: to not only set the array, but also reload the tableview. From the line, there's no indication of that behavior. If I were to see [myController setContentArray:newArray];, then I would think "Aha, a method. I need to go see the definition of this method just to make sure I know what it's doing."
So I think my summary of Beef #2 is that you can override the meaning of dot syntax with custom code.
Beef #3: I think it looks bad. As an Objective-C programmer, I'm totally used to bracket syntax, so to be reading along and see lines and lines of beautiful brackets and then to be suddenly broken with foo.name = newName; foo.size = newSize; etc is a bit distracting to me. I realize that some things require dot syntax (C structs), but that's the only time I use them.
Of course, if you're writing code for yourself, then use whatever you're comfortable with. But if you're writing code that you're planning on open sourcing, or you're writing something you don't expect to maintain forever, then I would strong encourage using bracket syntax. This is, of course, just my opinion.
Recent blog post against dot syntax: http://weblog.bignerdranch.com/?p=83
Rebuttal to above post: http://eschatologist.net/blog/?p=226 (with original article in favor of dot syntax: http://eschatologist.net/blog/?p=160)