On Dec 2, 2009, at 1:47 PM, David Hirsch wrote:
This is quite helpful, Quincey, but one thing you wrote surprises me:
If you have a simple 'int' property backed by a single 'int'
instance variable, changing the variable directly in your class
implementation will not generate any KVO notifications. Changing
the *property* -- which in that case means calling the setter
method -- does generate KVO notifications. Of course, the setter
implementation changes the backing variable.
Is that true, even if I write my own setter method (without
willChange/didChange)? If so, where is the notification coming from?
When the first KVO observer starts observing a property of an object
of your class, that object is altered in a pretty fundamental way.
Its class is changed to be a dynamically-generated subclass of your
class. In that subclass, all of the methods which match the KVC
patterns for setters of observed properties are overridden. So, if
somebody is observing your "foo" property, then your -setFoo: method
is overridden with one that calls -willChange..., calls your
implementation (via "super"), then calls -didChange....
Well, that's one way of thinking about how it might be implemented.
Don't pay much attention to how it actually is implemented. The
important thing to remember is that it works if your accessors follow
the naming conventions.
Another thing I'll add to Quincey's explanation: not only is it
important to understand the distinction between properties and the
ivars that might back them, it's important to recognize that KVO
observes the object which has the property for changes in that
property. Don't think of observing the property directly. It's
observing the object for changes in its property.
Why is this important? Because then you can recognize that everything
which generates KVO notifications must message the object which has
the property. Either you invoke one of the accessors which conform to
the naming conventions or you invoke -will/didChange..., but only
through messaging the object that has the property can you generate
the appropriate change notifications.
Think about the method that gets invoked on the observers: -
observeValueForKeyPath:ofObject:change:context:. The object gets
passed to that method in the second explicit parameter (self and _cmd
are implicit parameters). How else would KVO get the object except
that the change notification initiates from it? (If you directly
mutate an array which backs an indexed collection property, KVO
couldn't possibly know which object owns the array. Same if you just
change an int ivar.)
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
