> On 7 Mar 2016, at 15:53, Peter Levart wrote:
>
>
>
> On 03/07/2016 01:59 PM, Paul Sandoz wrote:
>>> On 7 Mar 2016, at 12:47, Peter Levart wrote:
>>>
>>> What about a Spliterator based on List.subList() method? While the
>>> specification of List.subList() does not guarantee any specific b
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
On 03/07/2016 01:59 PM, Paul Sandoz wrote:
On 7 Mar 2016, at 12:47, Peter Levart 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 implementati
> On 7 Mar 2016, at 12:47, Peter Levart 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
> On 7 Mar 2016, at 12:35, Michael Hixson wrote:
>
> Hi Tagir, Paul,
>
> Ah, it looks like Donald Raab had exactly the same suggestion. Sorry
> for the repeat. I was following that list at that time, and now I'm
> wondering whether my idea was my own. I agree with everything he
> said.
>
>>
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
Hi Tagir, Paul,
Ah, it looks like Donald Raab had exactly the same suggestion. Sorry
for the repeat. I was following that list at that time, and now I'm
wondering whether my idea was my own. I agree with everything he
said.
> One problem which would arise is that such spliterator will not be a
Hi Michael,
It could, stay tuned for some possible action on this.
This is something we did discuss a while ago [1]. At the time we thought most
List implementations would override so did not bother, and admittedly with the
frenzy of all other stuff got de-prioritized. But, perhaps we underesti
Hello!
I thought about such possibility. One problem which would arise is
that such spliterator will not be able to properly track modCount and
throw ConcurrentModificationException. As a consequence it might
produce silently inconsistent result if the structural changes were
performed on your lis
The default List.spliterator() is iterator-based. Could this be
improved for random access lists, using List.get(int) to fetch
elements instead of List.iterator()?
I think it could improve most on Spliterator.trySplit(). The current
implementation allocates a new array for split-off elements. I
10 matches
Mail list logo
