Re: Why do I receive KVO notification when new value IS the old value?
Re: Why do I receive KVO notification when new value IS the old value?
- Subject: Re: Why do I receive KVO notification when new value IS the old value?
- From: Quincey Morris <email@hidden>
- Date: Wed, 8 Jul 2009 16:20:00 -0700
On Jul 8, 2009, at 15:05, Jerry Krinock wrote:
Why do I receive KVO notifications when a key is set to the same
value that it already is?
This happens not only when the new and old values are -isEqual:, but
when they are identically the same pointer. I can't think of any
reason why anyone would want notification of a no-op.
I understand that it's easy enough to filter these out in my
observer methods, but it's certainly a waste of CPU cycles. I
wonder if maybe Apple calculated that, in their implementation, it
is on average less CPU cycles for me to filter them out in the
notifications I actually receive, as compared to Cocoa filtering all
notifications before posting?
Excuse me while I put on my properties-are-behavior crusader's hat. :)
KVO notifications are generated when a *property* is set by an
accessor. A property is behavior, not data, a most important fact that
mostly gets overlooked. Yes, for many properties, the setter behavior
is to set the new value into an instance variable, but this is an
internal detail.
Therefore, the KVO notification is not notifying you about the value
of the property, it is explicitly telling you that the setter behavior
was invoked. The equality of the getter and setter values just doesn't
come into it.
As a convenience, the notification includes the old and new values
(when requested), but those values are the return- and parameter-
values of the getter and setter respectively, and again their equality
doesn't tell you whether the internal state of the property has changed.
Other responses have given plenty of examples when behavior is not
locked to a stored data value. Another good example is invocation-
based undo. When undoing an action, all setters that were called
during the action need to be called again, in the correct order, even
if the getter value doesn't change as a result.
And, just flog this horse a little deader, it is not in general
functionally identical to coalesce KVO notifications. A notification
specifying a change from value A to value B, followed by a
notification of a change from B to C, is not the same as a
notification of a change from A to C -- not in general, although in
many specific cases the difference does not matter.
I presume that, for example, Cocoa's NSControl subclasses must all
be checking for equality before redrawing in responding to a KVO
notification?
Not necessarily. Most drawing is buffered these days, so we wouldn't
necessarily see all the redrawing. But maybe some do check.
_______________________________________________
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