1) The specification of Observable states that: "An implementation of
{@code Observable} may support lazy evaluation [...]"
It seems to me that this is an optional feature, and a user of this
API must be aware that any particular Observable implementation may
not support it, or that it chooses to
>
> As mentioned already, if we make any change in this area, it will need
> to be very well-tested, and even then we risk breaking applications.
>
I can make the change and can fix some of the tests (which will probably
mean deleting some of them since they explicitly rely on this behavior).
Some
That's a good idea to dig into the history further. I looked through the
closed-source repo, and the behavior of calling get to validate the
observable when adding an InvalidationListener for bindings has been
there pretty much from the beginning, even before the creation of the
ExpressionHelpe
I agree with Nir on this point. I don't see the middle ground as being
all that useful in practice, just more complicated, and the
specification change would be odd.
So I think we either go with the proposed change (and it would need to
be well-tested), or leave it as-is, where every new inval
I disagree with this interpretation. Observable says
> Implementations in this library mark themselves as invalid when the first
> invalidation event occurs. They do not generate anymore invalidation events
> until their value is recomputed and valid again.
And ObservableValue says
An Observab
The documentation of `Observable` states that "an implementation [...]
may support lazy evaluation" and that "implementations [...] should
strive to generate as few events as possible".
This seems to me like it would be within spec to fire an invalidation
event for every single change. It would als
Is it possible to dig in the history of ExpressionHelper a bit further?
In git it seems limited to 9 years ago, but in JIRA I found this bug report:
https://bugs.openjdk.java.net/browse/JDK-8119521
It describes an issue where an InvalidationListener is not working
correctly (according to t
I would also answer "no" to both points. This is also what the docs say.
So the question is: how likely do we think that changing this behavior will
> break existing applications?
>
That's the main question. I tested the JavaFX code with the new behavior
and some tests break immediately, though a
Given that the intention of InvalidationListener was to be a
light-weight way to listen to properties without causing a binding chain
to be revalidated, it does seem reasonable to me that the listener is
only fired on the valid --> invalid transition, which is the specified
behavior, even if th
I think that we need your input on this to move it forward.
On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker wrote:
> so the value field should perhaps be nulled out when bound.
>
>
> There was a PR for something like that in the old repo:
> https://github.com/javafxports/openjdk-jfx/pull/110
>
> On Fr
>
> so the value field should perhaps be nulled out when bound.
There was a PR for something like that in the old repo:
https://github.com/javafxports/openjdk-jfx/pull/110
On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx wrote:
>
>
> On 02/09/2021 11:57, Nir Lisker wrote:
> > So in order
> >
On 02/09/2021 11:57, Nir Lisker wrote:
So in order
to make sure that a new interested invalidation listener does not miss
the fact that a property was *already* invalid, the easiest solution
might have been to revalidate it upon registration of a new listener
But why does an
>
> So in order
> to make sure that a new interested invalidation listener does not miss
> the fact that a property was *already* invalid, the easiest solution
> might have been to revalidate it upon registration of a new listener
>
But why does an invalidation listener need to know the past state
On 31/08/2021 17:52, Nir Lisker wrote:
Hi,
This is a continuation of the discussion that stemmed from changing
bidirectional bindings to use invalidation listeners instead of change
listeners [1].
The relevant issue in JBS is [2].
I have looked at removing the eager evaluation when attachin
Hi,
This is a continuation of the discussion that stemmed from changing
bidirectional bindings to use invalidation listeners instead of change
listeners [1].
The relevant issue in JBS is [2].
I have looked at removing the eager evaluation when attaching an
invalidation listener. I found that tes
15 matches
Mail list logo
