On Jan 26, 2015, at 23:32 , Jerry Krinock <je...@ieee.org> wrote: > > You seem to be saying that the only example given by Apple is a bad example, > because it is a a nontypical, special case. I mean, most attributes in most > apps are objects, not scalars.
I’m not sure that it’s “bad”, though it is nontypical, which is why there’s a [nontypical] custom accessor. A slightly different, but more plausible, case occurs when your property has (say) a NSPoint value. A point can be boxed in a NSValue object, but you might find it undesirable to keep boxing and unboxing, if the property is frequently accessed. To do that, you’d actually need to store the point unboxed, which means you need a real ivar. What I think the documentation should say, but doesn’t lay out at all clearly, is that a Core Data property access has two general steps: 1. Representation of the value in backing storage. 2. Transformation of the backing storage value to vended @property value. Ideally, and often, both steps are trivial — null, in fact. In that case, Core Data does all the work for you, and you do nothing except fake the compiler out by providing definitions of what Core Data will provide at run time. For example, if your Core Data model declares a string value, Core Data will normally represent it in its internal backing store as a NSString value, and clients using the property will see a NSString object. But, you can customize one or both of these steps. For example, a scenario described in the documentation, you can customize step 2 to transform a NSColor object to/from a NSData object, which can be stored without a customized step 1. This is complicated because Core Data supports multiple methods of transformation, including NSValueTransformer and custom accessors. And by the fact that KVO can independently bridge between scalar property values and boxed object values as necessary. At the other end, you can customize step 1 by providing a non-object ivar, or by a collection of related ivars, or by a collection of primitive Core Data properties, or … . Depending on what you do, you may or may not need to customize step 2 as well. Clearly, all this customization takes some coordination between steps 1 and 2, even if it’s just to know which of them needs to be customized in any particular case, and how. That where the documentation falls down — it gives recipes for a couple of scenarios, without helping you understand how to figure out other scenarios. > It still persists! Oh, well, it was a theory. _______________________________________________ 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
