ObservableList bulk methods contract

[John Hendrikx]

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