We now have the "dot" notation for properties. I've seen various back and forths about the merits of dot notation vs. message notation. To keep the responses untainted I'm not going to respond either way in the question.
What is your thought about dot notation vs. message notation for property accessing?
Please try to keep it focused on Objective-C - my one bias I'll put forth is that Objective-C is Objective-C, so your preference that it be like Java or JavaScript aren't valid.
Valid commentary is to do with technical issues (operation ordering, cast precedence, performance, etc), clarity (structure vs. object nature, both pro and con!), succinctness, etc.
Note, I'm of the school of rigorous quality and readability in code having worked on huge projects where code convention and quality is paramount (the write once read a thousand times paradigm).
This is a great question and I see many different answers to this. Although many have touched upon the topics, I will try to answer this from a different angle (some might have done it implicitly):
If we use the 'dot' notation, the resolution of the target for the method is done at compile time. If we use message passing, the resolution of the target is deferred to run-time execution. If the targets are resolved at compile time, the execution is faster, since resolving the targets at the run-time includes a few overheads. (Not that the time difference will matter much). Since we have defined the property in the interface of the object already, there is no point in differing the resolution of the target for a property to run-time and hence dot-notation is the notation that we should use for accessing property.
I'm a new Cocoa/Objective-C developer, and my take on it is this:
I stick to the messaging notation, even though I started with Obj-C 2.0, and even though the dot notation is more familiar feeling (Java is my first language.) My reason for this is pretty simple: I still don't understand exactly why they added the dot notation to the language. To me it seems like an unnecessary, "impure" addition. Although if anyone can explain how it benefits the language, I'd be happy to hear it.
However, I consider this a stylistic choice, and I don't think there is a right or wrong way, as long as it's consistent and readable, just as with any other stylistic choice (like putting your opening curly brace on the same line as the method header or the next line).
In my opinion, the dot syntax makes Objective-C less Smalltalk-esque. It can make code look simpler, but adds ambiguity. Is it a
struct
,union
, or object?Use dot notation (whenever you can)
On instance methods returning some value
Do not use dot notation
On instance methods returning void, on init methods or on Class method.
And my personal favorite exception
OK, dot notation in Objective-C looks strange, indeed. But I still can't do the following without it:
Works fine, but:
Gives me "Cannot convert to a pointer type". I'd really like to keep my code looking consistent with message notation, though.
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:
andfoo
methods of an objects, yet still access them viasomething.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 callmyController.contentArray = newArray;
, I would expect it to be replacing the old array with the new array. However, the original programmer might have overriddensetContentArray:
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)