On 03/07/2016 01:59 PM, Paul Sandoz wrote:
On 7 Mar 2016, at 12:47, Peter Levart <peter.lev...@gmail.com> wrote:
What about a Spliterator based on List.subList() method? While the
specification of List.subList() does not guarantee any specific behavior when
underlying list is structurally modified, the implementations (at least
implementations in JDK based on AbstractList) do have a fail-fast behavior and
there's a chance other implementations too.
We currently have as the @implSpec:
* @implSpec
* The default implementation creates a
* <em><a href="Spliterator.html#binding">late-binding</a></em> spliterator
* from the list's {@code Iterator}. The spliterator inherits the
* <em>fail-fast</em> properties of the list's iterator.
Note the inheritance clause, which also covers the sublist case.
We would need to update with something like:
"If this list implements RandomAccess then…. and the spliterator is
late-binding, and fail-fast
on a best effort basis if it is detected that this list (or any backing list if
this list is a sub-list) has
been structurally modified when traversing due to an change in size as returned
by the size()
method."
Paul.
Hi Paul,
I don't think you understood my hint. I was thinking of a Spliterator
implementation for RandomAccess List(s) that would leverage
List.subList() method to implement splitting and/or fail-fast behavior.
As there is a good chance that sub-list implementations already provide
fail-fast behavior for structural changes in the backing list. For example:
Spliterator<E> spliterator() {
List<E> subList = subList(0, size());
return
IntStream.range(0,subList.size()).mapToObj(subList::get).spliterator();
}
This is a simple variant of Tagir's eager-binding RandomAccess
spliterator which is fail-fast if the List's sub-list is fail-fast.
Regards, Peter
