I'm pretty confident that this isn't actually required by the JavaFX
threading model, but it makes the code more obviously correct and
uncontended synchronization has a negligible cost when we're talking
about UI-level changes.
If the new output is equal to the old output, we'll suppress the change
message altogether, so as not to do unnecessary recalculations.
E.g., imagine you have a property `isOdd`. If you go from 27 to 319,
there's no need to trigger all the downstream objects to recalculate.
(Most of the other functional primitives I've created already have this
behavior.)
This is not yet tested, and it requires a lot of testing. A previous
helper that attempted to support `bind` never quite worked correctly,
but I believe that the new approach of implementing `join` and `map`
instead of `bind` makes the code more resilient.
Even though `map` and `ap` can be derived from `point` and `bind`, I'm
keeping both of them, as `bind` requires quite a bit of subscription
manipulation. Those methods have much simpler implementations.
This could prevent it from updating values if you returned to
the original value. E.g., if your values went 1, 2, 1, 2, you'd
get notifications for 1, 2, 2. This would also cause some extra
notifications to go when the logical value didn't actually change.
This commit also includes an `observe2`, which operates directly on a
tuple without explicitly converting to an HList. I'm committing it for
posterity, but the next commit will remove it because it doesn't give a
narrow enough output type.
Sarah Gerweck