On Tue, 10 Mar 2026 15:48:44 GMT, TomaszSzt <[email protected]> wrote:
> Also any reliance on _"if listener A was registered before listener B, then A
> will get called before B"_ is a horribly bad idea. Please, do not even try to
> suggest it. Simply do not. There is no way to ensure that ordering in any
> system of some major complexity.
This is the case right now and will be after this PR.
> My recommendation is: if You really plan to change in-place firing to some
> more sophisticated algorithm **do not do it**. Not in a stable production
> code. Recommend, inform, educate about possible side effect, alternatively
> add like "orderedFireXXX" methods or something, but do not change such an
> essential algorithm. As you can see above delegation is a simple method which
> allows programmers using the library to decide what is important from them
> and what is not. If they see problems with ordering delegation solves it. If
> however you will build it in, they will have no way to ensure that if they
> have problems with:
I still don't get your point. This is about nested changes and that the old
value is misleading or simply incorrect. You talked about state consistency,
but currently, this can happen:
myProperty.addListener((_, oldValue, newValue) -> {
// Here, oldValue MIGHT not be the last set value, but there value before
that.
// Instead of A -> B -> C
// oldValue can be A and newValue be C. Which is very bad when you want to
remove/unregister the old value.
}
This PR corrects that to BE consistent, so the `oldValue` will be B in this
example. This is consistency for me.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-4267122401
