[reactive] FRP, continuous time and concurrency
daniel.buenzli at erratique.ch
Tue Jun 9 15:54:28 EDT 2009
I don't think the push/pull issue is relevant to the discussion about
frp and the OO observer pattern. The push/pull issue is an (important)
implementation detail of FRP.
Le 9 juin 09 à 19:09, Álvaro García Pérez a écrit :
> This has similarities to the OO Observer pattern (in fact, you can
> implement it using the pattern) and is also supported in some new
> scripting languages as JavaFX.
One thing the observer pattern doesn't give you is any guarantee on
the order of updates: when the observed value changes it updates all
the observers in no specified order. However if a value observes more
than one value this may result in glitches (i.e. values you actually
don't want to see).
For example suppose your value dependencies are as follows :
a = b + c
b = c + 1
i.e. a observes b and c, and b observes c and initially we have :
c = 0
b = 1
a = 1
If c updates from 0 to 2 any of the following two sequences of updates
may be seen with the OO observer pattern :
c = 2; a = 3; b = 2; a = 4;
c = 2; b = 2; a = 4;
But usually you don't want to see the a = 3, it's a glitch. FRP
systems update the graph of dependencies in topological order (i.e.
they ensure before updating a value that each value it depends on has
been updated) and you are guaranteed you'll only see the second
sequence of updates.
FRP can be seen as a form of value observation in the sense that
changes in a value get eventually propagated to other values that
depend on it. But it is clearly not the same as the OO observer
pattern as usually understood/implemented because of this ordering
issue. FRP is more subtle and powerful in the management of the
value's dependency graph.
More information about the Reactive