[reactive] FRP, continuous time and concurrency

Daniel Bünzli 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 mailing list