On Dec 18, 2016, at 12:17 , Frank D. Engel, Jr. <fde...@fjrhome.net> wrote: > > I had been using @dynamic for object types and @synthesize for basic types > (such as BOOL and int). It seems I will need to create the accessors then > for the basic types as I just tried and @dynamic does not work for those.
You have to be careful what you do. Core Data model properties are always object types. If they represent a BOOL or integer value, their object type is NSNumber. If, for convenience, you want to have properties with scalar (“basic”) types, you can define your own, but they cannot have the same name as the Core Data property that underlies them. Also, you cannot @synthesize them, because that would leave them unconnected to the underlying properties. Instead, you must write your own getter and setter, and each should get or set the object value of the underlying property. Note that it used to be true (and may still be true, although the latest dumbed-down guide doesn’t say) that custom properties of managed object were *not* KVO-compliant automatically — it was necessary to code the did/willChange invocations of custom properties manually. If this is still true, and you bind anything to your custom properties (remember they have different names from the model properties), then you would have to implement the KVO compliance too. A couple of side issues: — You *can* add custom properties to a managed object subclass that don’t correspond to model properties. These don’t get saved with the model. That makes them useful only for transient values. — If you think you need scalar (BOOL and integer) properties just because you’re binding something in the UI that expects a scalar value, then you don’t need the scalar convenience properties at all. The binding actually expects a NSNumber type as determining whether the value is numeric. It’s a piece of KVC internal magic that translates a scalar value into a NSNumber when the binding requests a value from a scalar property. The “for convenience” I mentioned above applies only when you want to refer to the value programmatically, and you do it often enough to care about repeatedly unboxing the NSNumber value in code. _______________________________________________ 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
