On Thu, 20 Feb 2025 03:08:33 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
>> John Hendrikx has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix fix for regression :) > > I've thought about it and I would like to hear what others think. I have a > behavior in mind that I find intuitive, but it doesn't mean others will. It > actually includes throwing SOEs when listeners fight to set a value, I don't > think it's an incorrect behavior (user's fault). Using your Z, A to D order, > where A and C change values, > > Z 0->1 > A 0->1; set 2 > Z 1->2; > A 1->2; no change > B 0->2 > C 0->2; sets 3 > Z 2->3 > A 2->3; if A sets 2 we will get a SOE because of recursive changes; let's > say A wants value>=2 and not ==2 > B 2->3 > C 2->3; no change > D 0->3 > D ignores set->2 event since it got a more updated value (tracked by the > progress value?) > B, C, D ignore set->1 event since they got a more updated value > > This should still preserve the 3 rules you outlined. Each listener reacts > immediately (depth first) and always in order. This causes the last listener > to act to be the one that determines the final value, and not the first one. > The ignored values end up being the later ones. > This, of course, doesn't deal with removal/addition of listeners. I think > that removal should work immediately as it does now, but still allow the > immediate notifications prior. About addition I'm still not sure. > > --- > > I want to take a boarder view again for a moment. I went back to > https://github.com/openjdk/jfx/pull/837 to make sure I didn't drift off > course. The fixes for change listeners only pertain to nested events, right? > Without nested events, even the current `ExpressionListener` works correctly, > yes? @nlisker Is there anything that still needs to be discussed at this point? I think that you found some interesting edge cases, but as most involved registering and removing listener on the same property on which you already have a listener, I think that those are more hypothetical than cases we need to document or remain compatible with. I think that this implementation operates well within the current specification (ie. it could be integrated without any documentation clarifications), but I'm open to specifying some behavior (as provided by JavaFX) explicitly so applications may rely on it more (if they aren't already). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2695313605
