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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
