site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com On Sep 30, 2008, at 8:38 AM, Michael B Johnson wrote: Thanks for all the insight. A few questions: On Sep 30, 2008, at 3:08 AM, Ben Trumbull wrote: @property (retain) NSColor* color; but since we may need to calculate it, we also map it to an instance variable _color: - Ben _______________________________________________ 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/site_archiver%40lists.apple... So I have a CoreData app (10.5.5, 64 bit only) that has a NSManagedObject that has an NSColor* that is part of its data model. Because this color is actually a computed value that we want to cache, it is declared as a property: ... this doesn't follow. That you need to calculate it doesn't mean it has to be in an ivar. Okay, here's my dilemma. I think I'm missing something fundamental. The behavior I want is: We want to calculate the "color" of the object lazily. The color is a computed property based on the thumbnail image of the object. The thumbnail is itself a computed property, based on the URL of the the thumbnail image. In other words, we only require a thumbnail URL - everything can be gotten from that. When we start up and have only a thumbnailURL, we're satisfied with that until we're asked for our color. At that point, we want to set the thumbnail property based on the thumbnailURL, and we then calculate the color based on thumbnail info. Once we've gone to the trouble of calculating the color, we want to save it out as part of our store, so we don't have to recache it at some later point. We do not want to save our thumbnail - it's too big, and we can easily get it from the URL. Sure. Nothing unusual about this. There's a chapter on it in the Core Data Programming Guide. "Non-Standard Persistent Attributes" The only way I could think of it to let me know at a glance whether the color property had been cached was to have an instance variable that I could check for nil. If it was nil, I hadn't cached it, and therefore would at that point. Otherwise, I knew it was already calculated, and didn't need to initialize the thumbnail for me to calculate it. Well, that's not the only way, but it's probably the easiest. The two most obvious possibilities are (a) call -primitiveColor and check its results for nil (after properly calling - willAccessValueForKey:@"color" of course) or (b) having an ivar bitfield and tracking the initialized state as a flag. So what's the right way to do this? Having ivars is fine. Unmodeled properties are useful for many things. But putting modeled persistent data in them in usually a mistake. While it's possible, and described in the documentation, I discourage it since it's nearly always a sign someone is driving in the wrong direction. Also, putting modeled properties in ivars is slower than just letting Core Data do its thing with the dynamic properties, so you ought to have an especially good reason before trying that. I'm obviously not aligned with the one true Core Data way yet :-) Probably the key concept here is the distinction between public v.s. primitive accessors, along with the abstraction of the actual memory allocations in NSManagedObjects behind the primitive accessors. This email sent to site_archiver@lists.apple.com