I've previously commented on the question of Objective-C dot notation. After some additional thought and programming, I've got more commentary.
Assuming that all these lines occur inside a class implementation, consider the following assignments:
1) self.foo = somethingOrOther;
vs.
2) foo = somethingOrOther;
vs.
3) [self setFoo:somethingOrOther];
All are similar and would appear to be interchangeable. But they're not. And how they are not depends upon declarations elsewhere. If foo has been declared (retain) in the interface declaration, 1) and 3) are distinctly different from 2).
The difference is that 1) & 3) may (depending upon the @property declaration in the @interface) retain or copy somethingOrOther while 2) will not. IMO, this is a much bigger deal than whether 1) self.foo hides the explicit function call of 3) [self setFoo:...].
I digress...
Whenever we program with code written by others we are dependent upon the "kindness of strangers" -- we depend upon those other coders (often far away in time and in space) to behave according to some set of standards. Despite years of wrangling over the minutiae of where braces go and whether tab characters are superior to space characters, what those standards are is largely less important than whether they are followed. A mediocre standard followed religiously is better than a perfect standard used sporadically. Standard ways of doing things mold your mental expectations, and you will see non-standard code as though it were standard code, opening the door to bugs which are difficult to find even though they are obvious.
Back to the three assignments...
Whether you believe in dot notation or not, all three of these things are basically similar, used for basically the same function (assignment to an ivar or instance variable), and they appear basically interchangeable. The fact that they are not interchangeable is the same kind of problem as a poorly followed standard.
In a bunch of code, it's easy to see:
self.foo = someObject;
and
foo = someObject;
and
[self setFoo:someObject];
as the same thing. One day you might sit down at the computer and be tired of writing 'self' and start using 2) instead of 1). You should avoid this temptation. It can lead to frustration if you don't remember that 1) & 3) use the property setter function and 2) does not. And if you do remember that, and you take advantage of it, you face the risk that someone else will not (and that someone may be you in six months, or six days, or even six hours).
As I said, IMO this is a much bigger problem than the question of whether 1) or 3) is superior.
I recommend an iron-clad standard that you use one (and only one) of these constructs. I don't care which one*. Or do not use the automatic generation of getters & setters (@property & @synthesize).
Just my toonie.
* I do note that using 2) means extra code everywhere you want to retain an object. This has the advantage of explicitness -- you see the code when it is being used. And the disadvantage of clutter -- there's extra "boilerplate" code around every assignment using retain -- which makes it harder to perceive the overall flow of the code.
