KVO dependent keys

[Christiaan Hofman]

According to the documentations there are now two ways to declare dependent keys for KVO (apart from deprecated ways): override +keysForValuesAffectingValueForKey:, or implement a method +keysForValuesAffecting<Key>. Is this true?

My problem here is that when I do the former, the KVO dependency does not work, but when I do the latter it does work. So is this an implementation bug or a documentation bug, or am I misreading the documentation?

BTW I want to override the general method because I have a lot of keys that have the same dependencies, so it seems more natural to override one method rather than implementing a large number of specific methods.

Christiaan

[Christiaan Hofman]

Post by Christiaan Hofman
According to the documentations there are now two ways to declare dependent keys for KVO (apart from deprecated ways): override +keysForValuesAffectingValueForKey:, or implement a method +keysForValuesAffecting<Key>. Is this true?
My problem here is that when I do the former, the KVO dependency does not work, but when I do the latter it does work. So is this an implementation bug or a documentation bug, or am I misreading the documentation?
BTW I want to override the general method because I have a lot of keys that have the same dependencies, so it seems more natural to override one method rather than implementing a large number of specific methods.
Christiaan

Small correction, of course I meant +keyPathsForValuesAffectingValueForKey: and keyPathsForValuesAffecting<Key>. That does not change the question.

Christiaan

[Andy Lee]

Post by Christiaan Hofman
Small correction, of course I meant +keyPathsForValuesAffectingValueForKey: and keyPathsForValuesAffecting<Key>. That does not change the question.

I have used both approaches and switched between them, probably for the same reason. As far as I know it works as advertised, and you're reading the "advertisement" correctly.

I recently was scratching my head over a similar problem where the Affecting<Key> method did not seem to work. I vaguely remember the reason was something like using the wrong name for a boolean property. I either had to include or exclude the "is" prefix, I forget which; in the end I think I may have renamed the property without the "is".

But if you're using the same <Key> in both approaches I can't imagine offhand why it wouldn't work. Is it possible you have a stale version of +keyPathsForValuesAffectingValueForKey: that you neglected to delete? Or, if you're combining the approaches, are you calling super in +keyPathsForValuesAffectingValueForKey:, so that it can use the default implementation, which looks for the +keyPathsForValuesAffecting<Key> method?

Maybe post both versions of your +keyPathsFor... methods as a sanity check?

--Andy

[Christiaan Hofman]

Post by Andy Lee

Post by Christiaan Hofman
Small correction, of course I meant +keyPathsForValuesAffectingValueForKey: and keyPathsForValuesAffecting<Key>. That does not change the question.

I have used both approaches and switched between them, probably for the same reason. As far as I know it works as advertised, and you're reading the "advertisement" correctly.
I recently was scratching my head over a similar problem where the Affecting<Key> method did not seem to work. I vaguely remember the reason was something like using the wrong name for a boolean property. I either had to include or exclude the "is" prefix, I forget which; in the end I think I may have renamed the property without the "is".
But if you're using the same <Key> in both approaches I can't imagine offhand why it wouldn't work. Is it possible you have a stale version of +keyPathsForValuesAffectingValueForKey: that you neglected to delete? Or, if you're combining the approaches, are you calling super in +keyPathsForValuesAffectingValueForKey:, so that it can use the default implementation, which looks for the +keyPathsForValuesAffecting<Key> method?
Maybe post both versions of your +keyPathsFor... methods as a sanity check?
--Andy

Sorry for wasting your time. I found the problem, a somewhat subtle mistype (not in the relevant key itself, but somewhere earlier in the implementation that led to an early return, that's why I overlooked it.)

And BTW, I did call super, in the way recommended by the docs (i.e. adding the custom keys rather than replacing super's return value).

Christiaan