On Dec 2, 2009, at 09:43, David Hirsch wrote: > Are there docs (other than the official ones, which in this particular area > are inscrutable to me) that discuss this idea of a proxy? I'd like to know > more on this topic, so as to avoid similar problems in the future.
I recommend you *do* familiarize yourself with the official docs, and I think it works best if you do it in response to actual code you need to write (like the code in this thread). In that case, you'll probably have an "Oh, so *that's* what it means!" moment to counteract the inscrutability. Some thoughts: 1. The KVC/KVO mechanism is kind of "archeological", meaning that different parts of it were added at different times, and so its API design is somewhat less, ahem, organized than if it had been designed all at once. (For example, there's an immutable array proxy that parallels the mutable array proxy we've been talking about, but there's no method to get it directly. You get it automatically under certain circumstances that are not precisely under your control, and are not precisely the same circumstances as the mutable version.) 2. The best single place to get all of the information is still NSKeyValueCoding.h -- the comments are definitive, and relatively concise. 3. When dealing with KVO compliance, you have to get your head around the idea that you are no longer dealing with arrays objects, but with array collection properties (more exactly, indexed collection properties) of a containing object. There are [optional] indexed collection accessors in the containing object, which may be used directly and are KVO compliant, OR you can use the mutable array proxy to access the property in with convenient NSArray-like semantics. The important point about thinking in terms of properties is that the property is *different* from the storage (typically an instance variable) by which it is backed. KVO-compliance (and KVC in general) are behaviors associated with the *properties*, not with the backing storage, which is "just" an implementation detail. Therefore, if you have a NSMutableArray as an instance variable (as you did), modifying the instance variable (as you did) has no effect on the KVO mechanism, because it is not modifying the property. That might sound strange, since obviously the next time you retrieve the property's value you'll get the modified value from the instance variable, but that's a kind of accident when you're thinking about properties conceptually. (And that's why the "My view doesn't update until the next time I do something to force it to update itself" question almost always signals lack of KVO compliance.) The same thing is true of non-array properties. If you have a simple 'int' property backed by a single 'int' instance variable, changing the variable directly in your class implementation will not generate any KVO notifications. Changing the *property* -- which in that case means calling the setter method -- does generate KVO notifications. Of course, the setter implementation changes the backing variable. In some cases, you can do the wrong thing -- change the instance variable directly -- and still be KVO compatible if you manually call the willChangeValueForKey:/didChangeValueForKey: methods (or the similar ones designed specifically for collections), but that approach is kind of frowned on, not to mention difficult to get right in general. _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
