> What in the world is that nonCompliantKVCivar? I tried it in my project, on
> the ‘rating’ property as in my YouTube video.
>
> - (void)setPrimitiveRating:(NSNumber*)newRating {
> rating = newRating ;
> }
>
> Does not compile. The compiler never heard of ‘rating’. Same result if I
> change it to _rating, m_rating or nonCompliantKVCrating. OK, so then I added
> an ivar: _rating, and now of course
> _rating = newRating ;
> compiles.
Remember that the compiler can't know anything about your model as all of that
is specified at runtime. I wouldn't have expected CD to be smart enough to
match up to a simply ivar declaration but it makes sense. Better, however, to
have a property declaration, which would also synthesize an ivar in modern
LLVMs (as of Xcode 5?).
> It still persists!
It will if you modeled it, which I didn't notice, but must be the case. It
won't if you simply define an ivar or a property on your class and implement
the relevant methods, however accurately.
> - (void)setPrimitiveRating:(NSNumber*)newRating {
> rating = newRating ;
> [super setPrimitiveRating:newRating] ;
> }
>
> Result: Compiler warning that my superclass (eventually, NSManagedObject) did
> not implement this method, a crash at runtime confirming that.
If we stop and think a moment, why would calling super ever work? This is still
Objective-C, and calling super is only valid when the class' superclass
implements the method. And I bet NSManagedObject doesn't...
> Conclusion: Primitive accessors are potentially useful but more study is
> needed to understand how they work, and in particular how to override them
> without breaking stuff.
Primitive methods are simply the methods for setting an objects values without
being noticed--i.e. w/o causing KVO or changes notifications to be sent. I am
sure you understand why. There is absolutely nothing magical about them,
because they need to be entirely un-magical to escape CD's notice. Therefore it
is really hard to break anything unless you deliberately do so (or deliberately
ignore compiler warnings).
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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
