(continued from part 1) On Sep 11, 2015, at 15:49 , Alex Hall <mehg...@icloud.com <mailto:mehg...@icloud.com>> wrote: > > Out of curiosity, why do I not need these but I *do* need insert and remove > methods for the property?
All standard UI elements use KVC to retrieve their values, or use bindings which uses KVC to retrieve its values. (This, incidentally, is why bindings have a to and a from even though they’re bi-directional. They necessarily use KVC to access the model end of the link, but it’s not necessary that they use KVC for the UI element end.) That means that all the data retrieval from an IB document follows a standardized KVC behavioral pattern that means all data goes through choke points ‘valueForKey:’, ‘setValue:forKey:’ and ‘mutableArrayValueForKey:’ (and a couple of others for properties modeled on NSSet API instead of NSArray). This consistency of behavior benefits everyone, and is the foundation of why IB can connect things with such generality. However, in code, you’re not restricted to these KVC choke point methods. You can, instead, invoke accessors directly. Indeed, that’s exactly what you’re doing when you use property getters and setters. They’re a convenient shortcut instead of having to use the key-based KVC access methods all over your code, yet still be able to leverage KVC features such as KVO compliance. In other words, this is why KVC properties are the same thing as @property properties. So, in code, you could invoke ‘countOfTweets’ directly, if you had defined that accessor (which you shouldn’t or don’t for other reasons). But code certainly can use the custom insert…, remove… and replace… accessors, with perfect KVO compliance, if that’s more concise that using the mutable proxy. As I’ve suggested before, KVC/KVO is the interesting and subtle piece of technology. Bindings are actually kind of uninteresting, except as an example of how powerful KVC can be. _______________________________________________ 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
