There has been some discussion in the online Objective-C community about the propriety of using "dot notation" to access properties instead of getter/setter methods. For those of you not up on the lingo and the language, Objective-C 1.0 had you use getter & setter methods to access object instance variables, so:
int foo = [someObject getFoo];
[someObject setFoo:newFooValue];
Objective-C 2.0 added properties, which are syntactic sugar in the compiler so that you can access these same getter/setter functions automatically by using the so-called "dot notation" which is commonly used in c and c++ to access members of struct
s (and therefore also members of classes, which are merely a special kind of struct). Like this:
int foo = someObject.foo
someObject.foo = newFooValue;
Clearly this newer syntax requires fewer square brackets and is more familiar to c/c++/c# programmers, but it also hides potential complexity. Is the code really just a memory access to a publicly available data member of the instance? Or is it a hidden method call of unknown complexity, possibly creating and tearing down multiple network connections in order to expend countless CPU cycles calculating an intermediate value?
The online discussion has been pretty civil as such things go. Here's what I think: the dot notation is less annoying to read than the bracket notation. That reflects my extensive background in c and c++ programming more than anything else. Over time, as I do more and more Objective-C programming, I'll find the brackets less painful and will use them more often.
The concern about hidden complexity has a certain initial appeal: OMG! That variable access could be a network connection! Yeah, it could. But in c++, the simple statement:
a = b + c
could be just as bad, because the '+' operator might be overloaded to do God knows what! And it is always possible that you might assume a simple getter routine is just a getter routine even in bracket notation, only to discover that it, well, you know...
It's important to keep a little perspective here. The person writing that code might have been an idiot. That's always true, even when you're reading your own code. But it might be a good idea to start out with the idea that they were reasonably smart and trying to do a reasonably good job.
And when that idea doesn't pan out, yeah, check to make sure that the getter and setter aren't accessing some server in Chelyabinsk every time you access a variable using dot notation :-).
update 20091009: I was working on an assignment for my iPhone Application Development class, and this came up. Any construct that lets you write the following code must be considered eeevil:
CGPoint drawAt = CGPointMake((320 - [drawImage size].width)/2, (240 - drawImage.size.height)/2);
Compare the yellow highlighted code with the turquoise highlighted code: they are essentially the same, but I definitely prefer the turquoise, no matter how much detail is hidden in the [drawImage size]
construct. Ouch.
Good perspective, Evan, especially with the operator overloading example. Maybe the moral of the story is "trust, but verify"?
Posted by: Jon Reid | 2009.10.09 at 03:21 PM