Re: Detecting reading a key in KVC
Re: Detecting reading a key in KVC
- Subject: Re: Detecting reading a key in KVC
- From: Remco Poelstra <email@hidden>
- Date: Fri, 12 Nov 2010 16:39:24 +0100
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@hidden)
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:
This email sent to email@hidden