keyPathsForValuesAffectingValueForKey: does it trigger changes recursively? - objective-c

Question

I'm reading the Key-Value Observing guide from Apple, and it hasn't explained one point in detail.
My question is: say I have a name property that's dependent on firstName and lastName, and I also have another property group that's dependent on name and gender.
Following the guide, I've written this
+ (NSSet *)keyPathsForValuesAffectingName {
return [NSSet setWithObjects:#"lastName",#"firstName",nil];
}
When writing the corresponding method for group, can I write it like this
+ (NSSet *)keyPathsForValuesAffectingGroup {
return [NSSet setWithObjects:#"name",#"gender",nil];
}
Or I have to add all the related properties
+ (NSSet *)keyPathsForValuesAffectingGroup {
return [NSSet setWithObjects:#"firstName",#"lastName",#"gender",nil];
}
Note that both group and name are computed, readonly properties.

Answer 1

If your questions means ...
Can keyPathsForValuesAffecting<key> be chained to indirectly affect keys through several dependant properties?
... then the answer is yes.
Edit: Apple's documentation on keyPathsForValuesAffectingValueForKey: confirms support for indirect dependent notifications.
Your last comment seems to suggest that you expect KVO notifications (indirect or not) being sent when directly changing an ivar. That's not the case. KVO relies on using the proper setter or on manually announce the change by sending will/didChangeValueForKey:

Answer 2

I'm pretty sure, that this will work, because it would be hard to let it not work.
Let us imagine, that you have three external (= different objects) observers for the properties.
What happens:
A. The opening door for KVO is a message didChangeValueForKey: to the observed object. If you have turned on automatic KVO, this message is sent automatically, when the setter for the key is called. (This is done in a dynamic generated subclass, which overwrites the setter.)
B. Then KVO code is triggered that looks semantically like this: (And it is simplified for only supporting keys, but not key paths.)
NSSet *observers = kvoBucket[key];
for( id observer in observers )
{
[observer observeValue:[self valueForKey:key] forKeyPath:key …]
}
C. With affecting keys there has to be a second loop, informing about a change of the depending properties. (I assume, that this list is generated at the initialization of the class' object or adding the observation.)
// Inform observers
NSSet *observers = kvoBucket[key];
for( id observer in observers )
{
[observer observeValue:[self valueForKey:key] forKeyPath:key …]
}
// Scan for affected properties
NSSet *keyOfaffectedProperties = affectedPropertiesBucket[key];
for( NSString *key in keyOfaffectedProperties )
{
// trigger kvo for affected property
}
No let us sit down on the developer's chair. He can duplicate the first loop into the second loop. In this case it would not work. But this is duplicate code. (And the real code is more complicated for sure.) Why should he do that? Everyone of us would say: I already have this code! Let's use it again:
- (void)informOberserversForChangeOfKey:(NSString*)key
// Inform observers
NSSet *observers = kvoBucket[key];
for( id observer in observers )
{
[observer observeValue:[self valueForKey:key] forKeyPath:key …]
}
// Scan for affected properties
NSSet *keyOfaffectedProperties = affectedPropertiesBucket[key];
for( NSString *keyOfAffectedProperty in keyOfaffectedProperties )
{
[self informObserversForChangeOfKey:keyOfAffectedProperty];
}
If there is no optimization, which makes recursion impossible or inconvenient, it should work. I would bet it works – But only a small amount of money. ;-)

Answer 3

Most people here have got the right idea but to confirm this I've set up a test project with exactly the same code mentioned in my question.
And the result: it works for both ways.