On Sat, 18 Feb 2023 19:29:05 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> Confusing me again here :-) Did you mean to say "breadth-first" where you > said "depth-first" ? > > Breadth first is for sure a lot easier, as the old values are much easier to > get correct for it. > > I've given depth first some more thought, but every approach I think of > requires some kind of stack or tracking of which listeners weren't notified > yet of the original set that we wanted to notify (and I think we'll need to > remember even more if there is another change before the first and second one > finishes). Yes, sorry, I meant breadth-first. We can go with that one. > @nlisker if we're going for breadth-first, shall I fix the cases for single > listeners as well (finish the notification before calling the same listener > again, instead of recursively calling into it?) I think that we need to be consistent, so barring any special reason for excepting single listeners from this change, I would say that we need to bring them in line with the generic listener. > Perhaps we could limit the explanation to just mentioning that its possible > the "new value" may not be the same as ObservableValue#getValue if nested > changes occured. Also, I'm curious why it would still be a bad practice to > modify the value again (now that the old values are always correct); I think > it's pretty much the standard pattern to veto a change (like a numeric field > rejecting out of range values or non-numeric characters). I'll think about what doc changes to make. We'll see what Ambarish thinks too. Vetoing seems like a normal use case, but maybe there's another way of doing it. I never delved into this. ------------- PR: https://git.openjdk.org/jfx/pull/837
