On Feb 28, 2012, at 11:46 AM, Mike Abdullah wrote: > On 28 Feb 2012, at 17:05, Keary Suska wrote: > >> I find it more useful to focus on KVO (Key Value Observing) compliance >> rather than KVC compliance, as although KVC compliance ensures KVO >> compliance, the reverse is not always true. > > Whoah! Wrong way round! To be KVO-compliant, you must be KVC-compliant too. > There are tons of examples of KVC-compliance without KVO-compliance though.
Although it is always best approach your statement is not completely true. Attribute and to-one relationships do not have to be fully KVC compliant to be KVO compliant. Consider dynamic/dependent properties as the most obvious example: they do *not* require a -set<key> method to be mutable. You don't even need to use the automatic dependent key tracking. There are even necessary reasons to bypass pure KVC, which is at least one reason that willChange/didChange exist at all. And further if you decide to override the KVC methods (-valueForKey: etc) you are bypassing KVC compliance significantly. Given that, you point is well taken that my advice may be poor for those who do not understand KVC compliance sufficiently, but on the other hand I don't see any problem with the logic of going in reverse--i.e. first determining what needs to be KVO compliant and then ensuring that compliance, which most often includes ensuring KVC compliance but not always, especially when one wants dynamic properties without ivar/property backing, which may have been a solution for the OP. Best, 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
