Op 12 nov 2010, om 13:37 heeft Graham Cox het volgende geschreven: > > On 12/11/2010, at 11:24 PM, Remco Poelstra wrote: > >> But if I do not override setValue:forKey: How does the KVC logic now that it >> should not try to call setValue:forKey: on my wrapper object, but on the >> enclosed dictionary instead? Do I not need to override setValue:forKey: and >> call [myDictionary setValue:forKey] there? just as with valueForKey:? > > My apologies, yes, you do need to do this. Which means you'll also need to > implement manual KVO notification using -willChangeValueForKey: and > -didChangeValueForKey: since your object's clients will be observing it, not > the internal dictionary.
Thanks. I hope overriding these methods will not destroy my performance too much. > > I'm not sure, but this could create a problem, in that > -willChangeValueForKey: MIGHT invoke -valueForKey: in order to cache the old > value that is about to be changed so it can pass it in the notification. That > will trigger another fetch, because the new value has not yet been set. > Result, an infinite cascade of fetches. This is easy to solve using a simple > lock flag, but it may not be needed (just be aware of the possibility). Yes, that happens. Not an endless loop, but every property is indeed requested twice, once by me and once by the system. Kind regards, Remco Poelstra_______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
