ReactFX: exploration of reactive programming for JavaFX (was: [announce] InhiBeans: mitigate redundant recalculations)

[Jonathan Giles]

Very interesting library! Keep up the good work.

-- Jonathan

On 5/02/2014 6:06 a.m., Tomas Mikula wrote:
> Hi all,
>
> InhiBeans evolved into ReactFX [1], which now includes reactive-style event
> stream compositions and more.
>
> Best regards,
> Tomas
>
> [1] https://github.com/TomasMikula/ReactFX
>
>
> On Mon, Dec 16, 2013 at 7:31 PM, John Smith <John_Smith at symantec.com> wrote:
>
>> Perhaps reactive programming is different from the problem Tomas is
>> solving, but I think a research project which combined some of the
>> principles of functional reactive programming (
>> http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf) with
>> JavaFX properties using Java 8 lambdas and streams would be quite
>> interesting and perhaps very useful.
>>
>> John
>>
>> -----Original Message-----
>> From: openjfx-dev-bounces at openjdk.java.net [mailto:
>> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tomas Mikula
>> Sent: Monday, December 16, 2013 9:19 AM
>> To: Richard Bair
>> Cc: openjfx-dev at openjdk.java.net
>> Subject: Re: [announce] InhiBeans: mitigate redundant recalculations
>>
>> As a matter of fact, I have. Only to the extent of the "Principles of
>> Reactive Programming" [1] course that is currently in progress on Coursera.
>> From what I have seen so far, it's all about asynchronous composition (with
>> emphasis on both "asynchronous" and "composition").
>> I didn't see it addressing this specific problem of multiple redundant
>> updates, but I might be wrong. The truth is, this problem doesn't even
>> exist if you don't have any eager observers (i.e. when you don't ever
>> attach any ChangeListeners, and InvalidationListeners only propagate
>> invalidation and never require the value to be recomputed). The problem is,
>> although you can design your component without any eager evaluation (JavaFX
>> bindings are already composed this way), you then bind a
>> Label.textProperty() to the end of a binding chain and it all becomes eager.
>>
>> Regards,
>> Tomas
>>
>> [1] https://www.coursera.org/course/reactive
>>
>> On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair <richard.bair at oracle.com>
>> wrote:
>>> Have you looked at https://github.com/Netflix/RxJava by chance? I've
>> been dying to see somebody do an RxJava in JavaFX ever since devoxx and it
>> looks like you may have inadvertently started down that path :-).
>>> Richard
>>>
>>> On Dec 16, 2013, at 8:09 AM, Tomas Mikula <tomas.mikula at gmail.com>
>> wrote:
>>>> On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula <tomas.mikula at gmail.com>
>> wrote:
>>>>> On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer <swpalmer at gmail.com>
>> wrote:
>>>>>> Interesting, no worse than John's pattern though.
>>>>>> I thought of using a try/finally to make sure release was called
>>>>>> and that naturally lead to thinking of try-with-resources, where
>>>>>> the "resource" in this case is a binding of some sort (or a wrapper
>>>>>> around a binding) that is invalidated on close() if needed.
>>>>> That is an interesting idea. I didn't intend blockWhile() to be safe
>>>>> with respect to exceptions, but merely
>>>>>
>>>>> void blockWhile(Runnable r) {
>>>>>    block();
>>>>>    r.run();
>>>>>    release();
>>>>> }
>>>>>
>>>>> Enhancement you are suggesting could be fleshed out as block()
>>>>> returning an AutoCloseable and the usage would be
>>>>>
>>>>> try(AutoCloseable a = relaxedArea.block()) {
>>>>>    obj.setWidth(w);
>>>>>    obj.setHeight(h);
>>>>> }
>>>> OK, done. I implemented both:
>>>> 1. added the blockWhile() method;
>>>> 2. made bindings AutoCloseable, and block() returns `this`.
>>>>
>>>> Tomas