On Wed, Jul 25, 2012, at 03:54 PM, Sean McBride wrote: > On Tue, 24 Jul 2012 14:04:12 -0700, Quincey Morris said: > >Another way of saying all this is that it may not be possible to > >(reliably) inform Core Data that an attribute has changed without > >changing the identity of the object that represents the value. > > :( And changing the identity means using a different object... hmmmm... > I guess since my object is basically a fancy wrapper of NSMutableData, I > could actually copy my object but not copy the composed NSData too...
I was going to recommend something similar. The inability to express mutation of a heavyweight model object is a serious shortcoming in KVC/KVO. Most of the time it works; objects generate the right change notifications and observers pick them up. But then some intermediate observer gets smart and says "aha, the old and new values are pointer-equal! I don't need to forward this change notification for my derived keys!" and the entire thing breaks down. I've filed bugs asking for richer self-description of key types (basically -isOrderedToManyRelationshipKey: and the like). Perhaps we should also have -isMutableObjectKey:. Either that or the framework should stop eliding forwarded change notifications just because the values don't compare pointer-equal. --Kyle Sluder _______________________________________________ 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
