Re: KVO dependent keys

On Jun 15, 2011, at 15:23, Andy Lee wrote:

> On Jun 15, 2011, at 9:04 AM, Christiaan Hofman wrote:
>> 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