default random access list spliterator

[Paul Sandoz]

> On 7 Mar 2016, at 15:53, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 03/07/2016 01:59 PM, Paul Sandoz wrote:
>>> On 7 Mar 2016, at 12:47, Peter Levart <peter.levart at 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.

Clearly not :-) I thought you were asking a general question on subList behaviour.

I see what you mean now, specify the default implementation to defer to subList.


> 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.
> 

Although that is not not late-binding nor is it terribly efficient (the spliterator of stream is an escape hatch, we should try to avoid it for critical stuff like that in ArrayList [*]). If there is a constraint to be relaxed i would prefer it be the fail-fast properties.


> On 03/07/2016 03:53 PM, Peter Levart wrote:
>> As there is a good chance that sub-list implementations already provide fail-fast behavior for structural changes in the backing list.
> 
> Ah, well... I checked AbstractMutableList in Eclipse collections and it doesn't provide fail-fast behavior for it's subList(s) unfortunately…
> 

Ok.

Thanks,
Paul.

[*] We did use it in the list implementation for Collection.nCopies, which defers to the stream implementation, which in this case is i think justifiable.