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-boun...@openjdk.java.net 
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tomas Mikula
Sent: Monday, December 16, 2013 9:19 AM
To: Richard Bair
Cc: openjfx-dev@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.b...@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.mik...@gmail.com> wrote:
>
>> On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula <tomas.mik...@gmail.com> wrote:
>>> On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer <swpal...@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
>

Reply via email to