[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A couple of questions about goops method parameters

From: David Thompson
Subject: Re: A couple of questions about goops method parameters
Date: Fri, 05 Sep 2014 16:50:54 -0400
User-agent: Notmuch/0.18.1 ( Emacs/24.3.1 (x86_64-pc-linux-gnu)

"Taylan Ulrich Bayirli/Kammer" <address@hidden> writes:

> Panicz Maciej Godek <address@hidden> 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 -
GPG Key: 0FF1D807
Support the FSF:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]