I agree, that's more of what I was thinking. On Dec 16, 2013, at 10:31 AM, 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 >>
