Re: A couple of questions about goops method parameters

[David Thompson <dthompson2@worcester.edu>]

"Taylan Ulrich Bayirli/Kammer" <taylanbayirli@gmail.com> writes:

> Panicz Maciej Godek <godek.maciek@gmail.com> 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