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_sm...@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-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
