> On 7 Mar 2016, at 15:53, Peter Levart <[email protected]> wrote:
>
>
>
> On 03/07/2016 01:59 PM, Paul Sandoz wrote:
>>> On 7 Mar 2016, at 12:47, Peter Levart <[email protected]> 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.
