Is it wrong to use the dot syntax as a getter?

I know that the . is a shortcut for a setter. Sometimes, I use that kind of code:

cell.textLabel.text = [NSString stringWithFormat:@"this is row %i", indexPath.row];

This works as expected, but I was wondering, is it better (or more correct mayb开发者_StackOverflowe?) to write

cell.textLabel.text = [NSString stringWithFormat:@"this is row %i", [indexPath row]];

Or, in other words, should I use the dot syntax only with the = operator, like

aTextField.text = @"whatever";

Any links/docs are welcome, thanks :)

PS. In case you didn't see the tag, I'm talking about iOS here.

---

Dot (.) is not only a shortcut for setter, it's shortcut for getter too. You can use dot for getter too. There is no problem, neither this is bad practice. From Obj-C 2.0 programming guide, "You can use the dot syntax to invoke accessor methods using the same pattern as accessing structure elements. The dot syntax is purely “syntactic sugar”". Note that, it is saying about accessor method, not only setter.

---

It's a matter of taste.

I prefer not to use the dot syntax for various reasons:

• When using dot syntax, it's much harder to find only the places in your code where you set an value. Search for setValue: is much easier than searching for .value

• As a long time C programmer, my brain is wired to associate the dot syntax with accessing struct members. I find it rather hard to get used to the dot syntax in a different scope.

• The setXY: syntax close follows the natural language much closer. Makes reading someone else's code so much easier.

---

"." is a shortcut for accessing a @property (which may, by the way, be readonly). From the syntax point of view whether this is a getter or a setter depends on the operand position:

self.enabled = NO; // setter
BOOL isEnabled = self.enabled; // getter
self.selected = self.enabled = NO; // this is OK too

---

It's coding style so neither is better.

I would note two things though.

As a long time Objective C code I prefer the [indexPath row] as it is consistent with the rest of the code and for a set I would use [aTextField setText:@"whatever"]

But if you need to use the . notation for keypaths the accessing the same variable via method notation in the same piece of code will seem odd.

Apple documentation says

Objective-C provides a dot (.) operator that offers a compact and convenient syntax you can use as an alternative to square bracket notation ([]s) to invoke accessor methods.

and

myInstance.value = 10;
printf("myInstance value: %d", myInstance.value);

The dot syntax is purely “syntactic sugar”—it is transformed by the compiler into invocation of accessor methods (so you are not actually accessing an instance variable directly). The code example above is exactly equivalent to the following:

[myInstance setValue:10]; printf("myInstance value: %d", [myInstance value]);

---

Using the dot syntax is not coding style or a matter of taste!

The dot syntax is for accessing properties. The message sending syntax is for dispatching methods. They are conceptually two different things. Legacy and backwards compatibility to Objective-C 1.0 unfortunately makes them interchangeable, which has caused allot of confusion.

Weather to user the dot-syntax or not is dead simple:

• If a public header declares something as property, then access it as a property using the dot-syntax, as the author of the interface explicitly intended!
• If a public header declares something as a method, then access it using the message sending syntax, as the author of the interface explicitly intended!
• Make NO exceptions.

The hard question is, should you declare something as a property, and thus tell your clients that doit-syntax should be used, or should you declare a method? The simple answer is:

• Use properties for states (is something).
• Use methods for behaviors (do/calculate something).

Another rule of thumb is that properties should be self-contained, there should be no other way to change the value of the property but to set the property itself. This is Not a hard rule, use common sense, many sensible exceptions exist. For example a hidden property that can be changed with setHidden:animated: method.