> On 2015 Jan 26, at 22:14, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Jan 26, 2015, at 17:55 , Jerry Krinock <je...@ieee.org> wrote:
>>
>> What in the world is that nonCompliantKVCivar?
>
> It’s just an ivar that was defined separately from this particular code
> fragment. It’s “non compliant” because Core Data doesn’t have a way of
> backing a property with ‘short’ scalar storage.
I don’t think so, Quincey. 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. The ‘rating’ I used as
an example is a NSNumber object. But I really don’t think that matters to this
discussion, so let’s move on…
> There’s sort of no point in doing exactly this, BTW …
> All that’s going on here is that Core Data doesn’t use ivars as backing
> storage for properties …
> This explains, a primitive accessor. It’s a rare thing, an un-duck …
All very good explanations.
>> So this instance variable is somehow tied to the persistent store.
>
> It’s not, though. You must have done something wrong that made it work (!). I
> have a theory about that, which I’ll get to in a moment.
I’m going to skip up to there now…
> My guess is that you provided an implementation of ‘setPrimitiveRating:’ (the
> setter), but that you *didn’t* provide an implementation of ‘primitiveRating’
> (the getter).
Your guess was correct. So I corrected that mistake and re-ran the experiment
with both setter and getter,
- (void)setPrimitiveRating:(NSNumber*)newRating {
_rating = newRating ;
}
- (NSNumber*)primitiveRating {
return _rating ;
}
> you will then have to do extra work to get the value to persist, since the
> ivar itself doesn’t”.
Nope. It still persists! Apparently, the persistent store is written by the
public accessor, and/or there is some magical connection between the public and
primitive.
But with my mistake corrected, the user interface now works again.
Essentially, the app works just the same without those trivial primitive
accessors and ivar, as with them. So far, we’ve done no harm.
But the useful thing is that, as Richard Charles claimed, and I’ve now
confirmed this, although the public accessors do not get invoked during Undo
and Redo operations, the primitive accessors do. So, provided that he
implements both the primitive setter and getter, he can slip some code into the
getter to post a notification of the value change.
_______________________________________________
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
