Hm,
I think ObservableList can hardly make such guarantees as that would be
implementation dependent, and thus FXCollections can't give such
guarantees either.
I suppose ObservableList could mandate this (just as Collection classes
can mandate a specific equals/hashCode behavior for valid
implementations), but I see no reason why FXCollections is making such
guarantees in the first place -- at most it could specify how it is
doing this change (ie. using setAll, instead of iterating and setting
each element individually) and the user can then conclude that this
"efficient enough" for their purposes, and should result in the fewest
possible changes -- but it would still be ObservableList implementation
dependent.
It may also lure users into thinking they can deal with a change
resulting from this action in a simpler fashion, while when listening
for list changes you should always follow the established pattern for
dealing with the change, and not come to rely on certain action being a
single change.
--John
On 23/04/2023 14:25, Nir Lisker wrote:
Hi,
ObservableList defines bulk operation methods like 'setAll', 'addAll',
'removeAll' etc. It does not specify that these operations should fire
one change. On the other hand, FXCollections relies, at least on
'setAll', to have this behavior in the methods 'copy', 'fill',
'reverse', 'rotate' etc. These all state that one change notification
is fired on the supplied ObservableList, but just calls its 'setAll',
so there is no actual guarantee that only one event will be fired.
Did ObservableList mean to specify that bulk operations are reported
as one change?
- Nir
