Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
- Subject: Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
- From: Jens Alfke <email@hidden>
- Date: Sat, 10 May 2008 11:40:54 -0700
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden