I don't see any opinions, so should I investigate option 2? - Nir
On Thu, Mar 29, 2018 at 4:36 AM, Kevin Rushforth <[email protected] > wrote: > Breaking existing apps is the one thing I worried about with the > suggestion of doing it without API changes. So to summarize I think there > are three possiblities: > > 1. Just make the current API lazy for observables with no resource for the > developer. This seems unwise for the reasons you point out. > > 2. Keep the existing API, but add new When(ObservableXxxxx condition, > boolean lazyEval) constructors (we can discuss whether the default should > be eager to preserve compatibility for apps that rely on the side effect of > eager evaluation or lazy to match what many developers might expect). > > 3. Something else. > > Unless there is a problem implementing #2 (ignoring the default for now), > that might be the way to go. It would be good to get some opinions about > this from other developers. > > -- Kevin > > > Nir Lisker wrote: > > Iv'e given the idea of using existing API some thought. > > When using primitives, the evaluation is always eager. A method that > returns a boolean (for example) will always be evaluated before it is > passed to When, regardless of the condition value. This precludes the > possibility of lazy evaluation in the scenario I've shown in the issue. > > When using observables, it's probably possible to do this. The > observable's value is computed (that is, computeValue() is called) during > the call to otherwise(...), specifically, when the invalidation listener > WhenListener is registered on the observable. I think it's possible to > register and deregister the listener depending on the condition's value. > Using this approach, a developer can wrap a method call in an observable, > as done in Bindings.createXxxBinding(Callable...). This is a bit of extra > work for the developer, having to create a binding. It'll also break > current behavior unless we do something like adding a constructor > When(ObservableBooleanValue condition, boolean lazyEval) and default the > current one to lazyEval=false. We could also use the "we told you so" line > for developers who rely on the current undocumented behavior. > > - Nir > > On Sat, Mar 17, 2018 at 1:39 AM, Kevin Rushforth < > [email protected]> wrote: > >> Conceptually what you describe sounds like a good approach to explore. >> >> Another approach worth exploring is to see whether this can be done >> without API change, using the existing API. I took a (very quick) look and >> didn't see anything that would preclude fixing this using the existing API, >> nor does the specification (javadoc-generated API docs) mandate the current >> behavior of eagerly evaluating both the "then" and "otherwise" conditions. >> Since it was only a quick look, I can't be sure. >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >>> Hello, >>> >>> I've proposed to work on a public API for binding.When that adds >>> capabilities for dynamic evaluation of the 'then' and 'otherwise' >>> arguments. Any comments? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8199560 >>> >>> - Nir >>> >>> >> >
