On Mon, 17 Feb 2025 23:47:57 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:

> With that I mean that when you add a listener to a property during its own 
> notification, that listener will not be called until a change occurs after 
> the notification completes (ie. the change must be triggered by some 3rd 
> party, not during the fire value changed callback).

OK, now I understand.

> > So in the first case, the value is corrected.
> 
> I'm unsure what you mean by corrected here

I mean compared to the old behavior. In the old behavior, the listener was 
notified with an incorrect old value, while with the prospective new code (with 
added listeners) the listener will be notified with a correct value. With the 
current new code the listener isn't notified at all. So, the behavioral change, 
instead of incorrect->nothing, will be incorrect->correct.

In the second case I listed, instead of the current nothing->nothing (no 
behavioral change), it will be nothing->correct.

> But is it a specified behavior or just an implementation artifact of 
> `ExpressionHelper`?

No, thankfully, very little is specified. This allows us to implement a more 
sensible behavior...

> For me, the main question would be: "Does it make sense for a listener added 
> during a notification to immediately partake in the notification that added 
> it?".
> ...
> * Notify new listeners near the end (because they're appended, not for any 
> other reason) as part of a higher level (top level?) change in all cases, 
> nested or not
>   *  This means a newly added listener even in the simple case gets the 
> notification of the one that added it (this may be quite surprising, and 
> we'll have to see if FX even builds if I do this :))
> * Never notify new listeners when an ongoing change is going on (ie. while 
> the property is "busy" in a callback)
>   *  This is the current implementation, and will probably do exactly what 
> ExpressionHelper does in 99.9% of the cases

I'm not sure myself if it makes sense since I've never done this and cared 
about the behavior. I suppose it could go either way. If the first way is too 
complicated, the second one (this PR) is also reasonable.

> One immediate problem however is that the `newValue` received may differ from 
> a direct `get`

I think it should be specified that these are the same, no?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664284987

Reply via email to