On Mar 30, 2014, at 13:03 , Rick Mann <rm...@latencyzero.com> wrote: > In my situation, the values are being set to something, not being set to nil > (they're accessed via property accessors, which take scalars). For some > reason, Core Data thinks they're nil, and so I was asking how it decides that.
Your question is somewhat unclear, because it’s unclear exactly what you’ve done, as described in this thread and an earlier one. Terminologically, properties aren’t “backed” by other properties, they’re backed by storage, which in most cases means instance variables. Core Data is a bit different because it doesn’t have [visible] instance variables or backing storage for Core-Data-defined properties. Instead, a property “xxx” is paired with another property “primitiveXxx” which has a private backing store. In a sense, “xxx” is “backed” by “primitiveXxx”, though I don’t recall this terminology being used anywhere. In your case, it sounds like you have a Core Data property “rect”, which uses other Core Data properties (“rectX”, “rectY”, “rectWidth”, “rectHeight”) to store the elements of its value. If that’s what you did, the “rect” *has* a backing store (accessible via “primitiveRect”), but you’re not *using* it. It would therefore be nil, and therefore produce an error if “rect” is defined as non-optional. In your case, “rect” is what is generally known as a "derived” property, and there’s a bit of a clash between that and Core Data, which doesn’t exactly support derived Core Data properties. (More specifically, it doesn’t have the concept of a Core Data property without a backing store and hence without a stored value.) If I’ve understood your Core Data configuration correctly, you have several ways to proceed: 1. You can make “rect” be an ordinary property of your Core Data object, so that it has no Core Data backing store. This is closest to what you seem to be aiming for, but it has the drawback that (for example) you can’t fetch or query using the property (AFAIK). 2. You can make “rect” be optional. Drawback obvious. 3. You can, when initializing objects with the “rect” property, also initialize “primitiveRect” to a non-nil object value. 4. You can change your implementation of “rect” to be in line with the Core Data documentation, which describes (basically) two sub-approaches: 4a. Keep the components of the rect in a custom object that is the actual value of “primitiveRect”, and encode/decode it at each reference to the public “rect” property. 4b. Keep the components in actual instance variables, so that there’s no encoding/decoding at each reference. You’re still expected to encode/decode or archive/unarchive it at load/save time, but since you say that “rect” is transient, I guess that won’t actually happen. Personally — if I ever used Core Data again, which I am blood-sworn never to do — I would choose the lowest-numbered of these options that doesn’t absolutely contradict your requirements. (Also, I’ll add since I’ve already run on so long, the reason you ended up in this pickle seems to be that you started from a premature optimization — you seem to have wanted to avoid packing 4 numbers into a single object.) _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
