Re: Dependent values that are not iVars
Re: Dependent values that are not iVars
- Subject: Re: Dependent values that are not iVars
- From: Quincey Morris <email@hidden>
- Date: Fri, 18 Dec 2009 11:57:13 -0800
On Dec 18, 2009, at 11:28, Kyle Sluder wrote:
> Please note that it is not correct to call -will/didChangeValueForKey:
> without actually changing the value. The KVO mechanism might just
> simply not send a notification at all. (Well, I guess it's valid, but
> you might see fewer observation notifications than you would expect.)
Really? I've never seen the slightest evidence that the KVO mechanism takes any notice of the value, or that didChange ever fails to trigger an immediate notification (except in the case where a notification for the same property is already in progress and therefore the recursive notification is suppressed). It *can't* compare values, because:
1. It doesn't know how. There's no standard definition of semantic object equalness in the frameworks.
2. The property is its behavior (its setter and getter method), not its value. Getting the same value, even the same value object pointer, twice doesn't mean that some internal state of the property isn't different (or that there aren't side effects), and setting the same value twice isn't redundant (and may have side effects) That's in general, although in simple cases where the property is backed by an instance variable there's no practical difference.
In any case, if change of value was required, there'd be no way of having purely dependent properties, since you'd at least need some kind of instance variable to hold the old state to check before triggering the notifications.
Maybe I'm misunderstanding the issue you have in mind?
_______________________________________________
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