[reactive] FRP, continuous time and concurrency

[Peter Verswyvelen]

While I don't agree that push/pull is not relevant, I totally agree on the
glitches of the observer pattern you described here, which IMO make the
observer pattern only really practical in a model/view setting, where the
view is observer and the model is the subject.
2009/6/9 Daniel Bünzli <daniel.buenzli at erratique.ch>

> 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.
>
> Best,
>
> Daniel_______________________________________________
>
> Reactive mailing list
> Reactive at haskell.org
> http://www.haskell.org/mailman/listinfo/reactive
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090609/4d0cc1c8/attachment.html