• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Subject: Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
  • From: Chris Hanson <email@hidden>
  • Date: Sat, 10 May 2008 18:53:31 -0700

On May 10, 2008, at 11:40 AM, Jens Alfke wrote:

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.

Not necessarily. You can simply return a constant YES for a read-only "dirty" property, and treat the property-change itself as the trigger you care about.


Even better, though, would be for code to observe only the properties of the object that it actually cares about.

The question is, of course, why not just use Core Data if you're going to be doing object-graph management? It's not a "beginner" technology, but that is what it's for, and the original poster would probably do well to take a look at it before going to far in the direction of implementing a completely different object graph management and persistence framework.

Plus, I'll bet the internal general-purpose dependency tracking is less efficient than the hardcoded call to -setDirty.

You would be surprised. For example, in the above case, the automatically-generated setters for the "bar" and "baz" properties may only post a KVO notification for the "dirty" property if it's actually observed.


There are a lot of things that can be done under the hood to be efficient when you work declaratively instead of procedurally. Not implementing accessors, and instead using declarative mechanisms like KVO, is one of those cases where the system can really help you.

  -- Chris

_______________________________________________

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


  • Follow-Ups:
    • Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
      • From: Ilan Volow <email@hidden>
    • Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
      • From: Jens Alfke <email@hidden>
References: 
 >Did I reinvent the wheel? (From: Western Botanicals <email@hidden>)
 >Cocoa coding style (was Re: Did I reinvent the wheel?) (From: Chris Hanson <email@hidden>)
 >Re: Cocoa coding style (was Re: Did I reinvent the wheel?) (From: Jens Alfke <email@hidden>)

  • Prev by Date: Yann Disser Resizing NSTableView columns
  • Next by Date: Re: Core Data: How to Observe "dirty" State?
  • Previous by thread: Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
  • Next by thread: Re: Cocoa coding style (was Re: Did I reinvent the wheel?)
  • Index(es):
    • Date
    • Thread