Re: NSManagedObject subclass accessor pattern mystery?
Re: NSManagedObject subclass accessor pattern mystery?
- Subject: Re: NSManagedObject subclass accessor pattern mystery?
- From: Ben Trumbull <email@hidden>
- Date: Tue, 30 Sep 2008 13:32:01 -0700
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:
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:
@property (retain) NSColor* color;
but since we may need to calculate it, we also map it to an instance
variable _color:
... 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.
- Ben
_______________________________________________
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