Re: Cocoa coding style (was Re: Did I reinvent the wheel?)

FROM : Jens Alfke
DATE : Sat May 10 20:40:54 2008

On 9 May '08, at 7:41 PM, Chris Hanson wrote:

> (6) Leverage Cocoa framework features in your own code.  For 
> example, you don't need to have setter methods that invoke -
> setDirty:.  You can just write a method like this
>    - (NSSet *)keyPathsForValuesAffectingDirty {
>        return [NSSet setWithObject:@"UUID"];
>    }
> and then anything that cares about whether a particular object is 
> dirty can observe its "dirty" property.


But you still need to implement the "dirty" property, with a getter 
that returns the corresponding ivar; and the other setters like -
setUUID: need to set the ivar to true.

So what you're describing comes down to just (a) removing -setDirty:, 
and (b) replacing the internal calls to it with "dirty=YES". Is this 
any simpler or cleaner? It's the same number of lines of code, and now 
if you add a new property to the class you have to remember to add its 
name to the set in keyPathsForValuesAffectingDirty. Plus, I'll bet the 
internal general-purpose dependency tracking is less efficient than 
the hardcoded call to -setDirty.

In addition,

* keyPathsForValuesAffectingDirty should be a class method, not an 
instance one

* You didn't point out that this only works on 10.5. On 10.4 it will 
compile without warnings but will be ignored at runtime, causing hard-
to-debug wrong behavior when your property dependencies fail to work.

—Jens