[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: JDK-8199560: Dynamic evaluation for binding.When
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2018-03-29 1:36:51
Message-ID: 5ABC4333.3010700 () oracle ! com
[Download RAW message or body]

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 
> <kevin.rushforth@oracle.com <mailto:kevin.rushforth@oracle.com>> 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
>         <https://bugs.openjdk.java.net/browse/JDK-8199560>
>
>         - Nir
>          
>
>
[prev in list] [next in list] [prev in thread] [next in thread]