Re: Making a bound view re-read its value
Re: Making a bound view re-read its value
- Subject: Re: Making a bound view re-read its value
- From: "Michael Ash" <email@hidden>
- Date: Fri, 15 Aug 2008 18:05:09 -0400
On Fri, Aug 15, 2008 at 2:02 PM, Quincey Morris
<email@hidden> wrote:
> On Aug 15, 2008, at 10:23, Adam R. Maxwell wrote:
>
>> Sending empty willChange/didChange messages is not a good idea:
>>
>> http://www.cocoabuilder.com/archive/message/cocoa/2008/5/18/207038
>
> Except that the idea of "non-empty" willChange/didChange messages doesn't
> cohere. The following is a perfectly legal setter:
>
> - (void) setX: (NSInteger) newX {
> [self willChangeValueForKey:@"x"];
> iVarX = newX;
> [self didChangeValueForKey:@"x"];
> }
>
> When this is called with newX == iVarX, it doesn't do anything except call
> willChange/didChange, so it's "empty" in that case, if "empty" had any
> meaning here. If there was some problem with "empty" setters, that scenario
> would fail. Does setting a property to its current value fail?
My understanding (and I may be wrong) is that an empty will/did pair
is not wrong by itself, but it implies that things are wrong elsewhere
in your program.
When a key is observable, then you *must* wrap *every* change to that
key in a will/did call pair. It doesn't matter how you do it, whether
it's code in your property, KVO's dynamic subclassing, or manual calls
scattered throughout your code, but they *must* happen every time.
Given the above, if you're doing things right, an empty will/did pair
is not wrong, but it is pointless. Since you've already notified
observers of every change you've made, there's no use in trying to
tell them about a nonexistent change. They already know about your
current value, there's no behavior to trigger.
The problem then is that the empty will/did pair is used as a
*substitute* for the proper calls. It's sometimes too hard to wrap
every change in a will/did pair, so instead people put an empty
will/did call *after* the change. It is this which ends up causing
problems. The "will" call is supposed to happen before the change
takes place, with the old value; that's the whole point of it, why
there's two separate calls. Some mechanisms depend on being able to do
something with both the old and new value, and they depend on you to
provide it (indirectly, by calling "will" before you erase it). Thus
use of an empty will/did pair, unless it's just being useless,
indicates that you have problems with your code which will in turn
cause problems with these mechanisms.
Mike
_______________________________________________
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