In Which I Embrace Dot Notation … 

I have a round trip story with early returns :). I was using early returns always, then I stopped due to company coding conventions and start liking it, but later I decide to use them in cases where it makes my code more clear. Readability wins.

Another one I have is about testing constructors. When I started TDDing I was always testing that the objects I was injecting in the initializer are set (I tend to use read only properties for the things I inject in the constructor) as well as the constructor throwing an exception when one of the parameters is nil(with STAssertThrows).

Later I found that writing and maintaing those tests is too much work so now – specially when you add or remove one parameter to a constructor, as this in ObjC implies changing its name, and Xcode is not making that easy – I only test that the properties are set but not the exception throwing. I still use NSParameterAssert(injectedParameter != nil) for every constructor argument, but the work of writing and maintaining those tests is not worth IMO.

Jon, do you use properties for your private ivars too? I have recently been using properties for everything except for private ivars which probably are not candidates to be KVObserved. I am using this convention to distinguish between:

public property access
-(void) abc
{
self.publicProperty = x;
}

public property in an accessor/mutator or init/dealloc
-(int) publicProperty
{
return _publicProperty; // we know this is a property because leading _
}

private ivar with no leading ‘_’
-(void) def
{
privateIVar = 20; // we know this is private and not a property because no leading _
}
I haven’t yet decided whether this is valuable.

Like you, Jon, I originally disliked the dot notation. I thought it introduced an ugly inconsistency between dots and square brackets for little benefit. However, about a year ago, I read an old article by Chris Hanson (http://eschatologist.net/blog/?p=226) that totally changed my thinking.

As Chris suggested, I had always seen dot notation as an alternate syntax for invoking methods. However, that short article changed the way I think about them, and I now use properties exactly as he suggests… as a way of signifying intent to the consumers of my classes.

—
Craig

I feel there’s a lot of pedagogical value in “[self setValue:[self value]+1]” (let’s not get into “self.value++”!). Then, once that value has been extracted an internalized, I prefer the readability value of “self.value+=1”. I have been opposed to “_value+=1” for quite a while now.

The two benefits I see of explicit square-bracketed message sending are A: there is no question that message sending is involved or how many messages are involved, and B: it forces realization that incrementing is a multi (3) stage process… load, calculate, and store. For students that still don’t get why “x=1; y=x+x; y=2;” will result in x having a value of 1, raising awareness of loads and stores helps clear out a lot of confusion.

Once I trust someone understands what’s going on under the hood enough, I’m happy to see “self.value += 1”, since I feel it communicates intent more clearly. Then again, [self incrementValue: 1] is easier on my eyes, but at the cost of non-standardness and having to create extra methods.

As for “_value += 1”, though, good riddance! Direct access of the *back*ing variable increases debugging difficulties, risks obscuring scope/ownership of the variable (mitigated by _naming conventions and/or IDE coloration assistance), couples the code to a particular implementation, and loses out on any freebies (e.g. memory management, KVO) provided by the accessors. I’ve had students prefix all their backing variables with “_DNU_” (and, for repeated transgressions, “_Do_Not_Use_”) as an unsubtle reminder to funnel access through accessors.

On a related note, I was quite delighted when it became possible to declare state in the implementation rather than the interface of a class. I’m also a big fan of @property.

I’ve just recently switched sides in the dot notation war, mostly due to Xcode 5’s often frustrating support for auto completing square brackets.

It is just easier and faster for me to type the dots than to interrupt my flow by having to manually correct Xcode’s often badly placed opening square bracket. TextMate was/is a lot smarter about autocompletion of message brackets. I probably should be using it more, but I’m lazy.

So really, laziness and Xcode editor irritation has finally worn me down. Xcode 5 doesn’t mess up dot notation nearly as much as it does square brackets. I do double-check headers to make sure I’m only using dots to access declared properties. Using dots only for property access is a pragmatic rationalization that I can get behind.

I too have come around to using dots…. a bit! I use them now, but only for getters. I don’t use them for setters because:
1) self.item = self.someMethodThatCreatesAnItem hides an unknown amount of functionality. [self setItem:…] makes it much clearer (to me) that self is getting changed.
2) Often, one has not only the [setItem:] method but also [setItem:withContext:] I find it icky to be able to write
self.item = item
in some cases, but in other cases be required to use this syntax:
[self setItem:item withContext:context]
Therefore, I always use [set…] syntax. This also makes it completely clear what to search for if I’m looking for all instances of calling the setter. I know I can search for “setItem:” and find every one.

Very often I think, “If ONLY the creators of Objective-C could have just been happy with the ()-based method-calling syntax of C”.

You haven’t fully embraced dot notation until you start writing

[[self prop] doSomething];

as

self.prop.doSomething;

and if that looks weird to you, then maybe there’s something wrong with dot notation.

Have you ever gotten a compiler warning for the perfectly reasonable looking:

self.view.frame.size.height += 12;

? Then maybe there’s something wrong with dot notation.