Closed GoogleCodeExporter closed 9 years ago
Actually, remove is never supported.
We should revise the Javadoc to say that. Thanks for pointing out this issue.
Original comment by jared.l....@gmail.com
on 27 Jul 2009 at 4:24
Remove is supported on the returned Iterable, but it won't update the array
passed in.
This is because the cycle method creates a new ArrayList and calls
cycle(Iterable<T>).
Original comment by abry...@gmail.com
on 27 Jul 2009 at 4:41
You're right; I thought the code called Arrays.asList() instead of creating a
separate
ArrayList. The documentation should be fixed.
Original comment by jared.l....@gmail.com
on 27 Jul 2009 at 4:56
Good catch.
Well, here's a stab at it, but it's definitely awkward.
* <p>Invoking the {@code remove} method on such an iterator causes the
* last-returned element to no longer appear as a future element in either the
* current iterator, or any other iterator produced from this same iterable.
* That is, this method behaves exactly as {@code
* Iterables.cycle(Lists.newArrayList(elements))}. The iterator's {@code
* hasNext} method returns {@code true} until all of the original elements
* have been removed.
*
thoughts?
Original comment by kevin...@gmail.com
on 27 Jul 2009 at 5:39
Ok, next RC will read like this
* <p>After {@code remove} is invoked on a generated iterator, the removed
* element will no longer appear in either that iterator or any other iterator
* created from the same source iterable. That is, this method behaves exactly
* as {@code Iterables.cycle(Lists.newArrayList(elements))}. The iterator's
* {@code hasNext} method returns {@code true} until all of the original
* elements have been removed.
Thanks for reporting this!
Original comment by kevin...@gmail.com
on 30 Jul 2009 at 1:31
Original issue reported on code.google.com by
abry...@gmail.com
on 27 Jul 2009 at 12:41