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 > > >
