Should KVO subscribables send their current value on subscribe?

[joshaber]

I'm starting to think +rac_subscribableFor:keyPath:onObject: should send the current value of the key path when it is first called. It already replays the last value, but it seems even better to ensure a subscribable for a property will always have the current value, even if it's nil.

[jspahrsummers]

Why not just accept KVO options (which include the option to receive an initial notification)?

[joshaber]

Maybe, but that'd require a bit more support for propagating the change dictionary. Which might be good to have anyways, but seems separate from this particular issue.

[Coneko]

I mostly call it from a macro, so it's easy to switch between RACAble and RACAbleWithStart depending on whether I want the initial value or not.

I don't think much of my code would break if this behaviour was changed, and even the parts that did break would be trivial to fix, but I'd still rather have the option to choose whether I want the initial value or not, after all you do get the option with vanilla KVO.

[jspahrsummers]

@joshaber The change dictionary is mostly orthogonal — just make it clear you can't get new/old no matter what. Initial and prior options are still really useful.

[joshaber]

Closing this for now. I think the real problem is that it can be hard to know if you need to use RACAbleWithStart instead of RACAble to get the behavior you want. This might just be papering over the issue.

[Coneko]

@jspahrsummers :

just make it clear you can't get new/old no matter what.

Why is this? -rac_addObserver:forKeyPath:options:queue:block: doesn't look like it would have issues with it.

[jspahrsummers]

I mean that you wouldn't be able to get KVO "diffs", like added/removed objects in an array (obtained from the KVO change dictionary, as generated by NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld), because that would mean that the signal is sending different kinds of values at different times.