"Taylan Ulrich Bayirli/Kammer" <[email protected]> writes:
> Panicz Maciej Godek <[email protected]> writes: > >> [...] it's hard for me to see the advantage of FRP over OOP in >> practical systems (e.g. windowed applications with buttons and so >> on). [...] > > An off-topic remark: > > I don't know about *functional* reactive programming but from my > experience so far as an iOS developer, I've been *longing* for a > reactive programming system that automates state changes even if not > fully hiding them. It would be invaluable being able to say > "button2.leftEdge = button1.rightEdge + 20px" and have this equation be > held automatically on changes to the layout of button1 (which might > happen because it itself reacts to other layout changes), or to be able > to say "button.disabled = condition1 or condition2" and have the > disabled status of button update automatically as the truthiness of the > conditions changes. (The former use-case is actually covered by "layout > constraints", but that's strictly limited to layouting.) > In my reactive programming system, you could say: (define-signal button2-left-edge (signal-map (cut + <> 20) button1-right-edge)) Which is, of course, more verbose than your example. I want to explore creating a macro that would abstract away the unboxing of signals so I could simply write... (define-signal button-2-left-edge (+ button1-right-edge 20)) ... and it would DTRT. Racket's FrTime can do this, which is neat. > Declarative programming FTW. > Agreed. :) -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate
