Aral Balkan

I read through Aaron Hillegass's excellent Cocoa Programming for Mac OS X book and I'm now going through it again, doing the exercises.

The second time round, I found it funny that in the chapter on key-value coding, Aaron mentions how he finds the new dot operator access of properties in Objective C 2.0 to be "a rather silly addition to the language since we already have a syntax for sending messages". Although I agree that having one way of doing things — also known as consistency — causes less confusion, it's unfortunate that this statement comes right after the section in which you write a method to increment an instance variable via its accessor methods:

-(IBAction)incrementFido:(id)sender
{
  [self setFido:[self fido]+1];
}

(In case the syntax of Objective-C throws you off, setFido and fido are accessor methods — in ActionScript the equivalent would be setFido(fido()+1) given that we don't have to explicitly refer to this (self in Objective-C) within an instance method unless there is ambiguity between a parameter name and a property name.

The irony is that, using the dot operator, the above method becomes:

-(IBAction)incrementFido:(id)sender
{
  self.fido++;
}

Thereby demonstrating a good use case for dot notation. :)

Comments

• The issue for me is that properties and direct access do not always produce equivalent behaviour. This is particularly true when using the 'retain' attribute in the property declaration to automatically retain an object when it is assigned to the member variable through a property. If you're not careful and use non-property syntax, the object will not be retained: @interface Bar : NSObject { Bar *nextBar; } @property (nonatomic, retain) Bar *nextBar; @end @implementation Bar - (void)setNextBarNoRetain:(Bar *)newNextBar { /// Does not use property scaffold and will not retain newNextBar nextBar = newNextBar; } - (void) setNextBarRetain:(Bar *)newNextBar { // Uses property scaffold and so will retain newNextBar self.nextBar = newNextBar; } @end This can lead to either memory leaks (if you're using property syntax and aren't expecting the retain behaviour, which is unlikely) or prematurely-released objects (if you're using standard syntax and expecting the retain behaviour). The latter is particularly frustrating as (AFAIK) there's no way to predict when the reference-counting garbage collector will allow that memory block to be overwritten.

  by Steve Webster on 2008-12-28 18:34:41

• [...] I started reading “Cocoa Programming for max OS X by Aaron Hillegass” (thanks to Aral Balkan’s post) Try to figure out which ORM we should use for our new timewax shell and future developments Try to [...]

  by So, how are you? « A Personal view on Webdev and other things… on 2009-01-30 17:50:46

• @Steve, for the reason you state, I prefer the following convention: @interface Bar : NSObject { @private Bar *_nextBar; } @property (nonatomic, retain) Bar *nextBar; @end @implementation Bar @synthesize nextBar = _nextBar; // any other access becomes more obvious when you use self.nextBar or _nextBar ... @end

  by Bill Shirley on 2009-01-19 20:46:16