On May 12, 2010, at 2:39 PM, Quincey Morris wrote: > On May 12, 2010, at 11:04, Ken Thomases wrote: > >> On May 12, 2010, at 11:44 AM, Quincey Morris wrote: >> >>> *All* collections emit KVO notifications when their contents change, in the >>> sense of objects entering or leaving the collection. Add, remove and >>> replace for arrays, add and remove for sets, set and remove for >>> dictionaries. >> >> Arrays and sets may (probably; I haven't checked) emit change notifications >> for their "count" and "description" properties when elements are added or >> removed. But they don't emit change notifications regarding the specific >> elements that they contain, which is what I think Keary was getting at. In >> particular, they don't emit a change notification of kind >> NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, or >> NSKeyValueChangeReplacement. > > Well, technically, they don't *emit* these notifications -- they are emitted > by KVO-compliant custom accessors and/or KVO-compliant mutable array/set > proxies.
But those don't operate on the collection objects (leaving aside "count" and "description" and the like). Both of the KVO-compliance mechanisms you mention only operate on objects with respect to a particular property. A KVO-compliant mutable array/set proxy does _not_ wrap the array or the set. It wraps the object and its property. All KVO change notifications always arise by messaging the object which has the property. They never arise by messaging the backing store that may be used to implement the property. > I have no idea whether NSMutableDictionary does literally emit > (will/DidChange...) notifications for setObject:forKey:/removeObjectForKey:, > or whether those methods are invisibly wrapped in KVO-compliant methods, just > like ordinary object properties when they're observed. I don't either and it's not relevant to what I'm saying. Invoking will/didChange... is not what I refer to when I say "emits change notifications". I'm referring to the effect: invoking -observeValueForKeyPath:ofObject:change:context: on the observers. > Either way, I'm not sure it matters a lot where the notifications come from. > My point was that KVO notifications of kind NSKeyValueChangeInsertion, > NSKeyValueChangeRemoval, or NSKeyValueChangeReplacement do happen when arrays > and sets are updated KVO-compliantly, just like KVO notifications of kind > NSKeyValueChangeSetting happen when ordinary object properties are updated > KVO-compliantly. No. That's incorrect. There's no such thing as updating arrays or sets KVO-compliantly. (Again, I speak in terms of their elements, not properties like count or description.) You can only update to-many relationship properties of some other object, which _might_ be backed by arrays or sets. There's no message you can send to an array or set object that will cause it to deliver NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, or NSKeyValueChangeReplacement change notifications to observers. You have to message (directly or through a proxy) some other object which has the to-many relationship property. Remember, such a property may not be backed by an array or set, so it's a mistake to think of even the proxies as forwarding to the collection object. Conceptually, the proxies forward to the object with the relationship. [This is blurred a little bit by KVO's (evil!) ability to directly access ivars, but the concept remains valid.] Again I refer to the arguments that might be passed to -observeValueForKeyPath:ofObject:change:context:. There's an "object" parameter there. That's the object which has the property. If you could message a free-standing array/set and cause it to send out KVO change notifications, what would be passed as the object? What would be passed as the "keyPath"? Those questions are easy to answer when you realize that all KVO-compliant messaging goes to the object that has the property, and references the property name explicitly or implicitly (by the name of the accessor method). Regards, Ken _______________________________________________ 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
