Fwd: Re: Stream.limit() - puzzler/bug/feature

[Brian Goetz]

> if we provide a spliterator(), we don't need the method iterator()
> because one can call spliterator().iterator().

The idea is:
  - If it's a serial stream, you grab an iterator() if you need direct 
element access.
  - If its a parallel stream, you grab a spliterator() if you need 
direct element access.

> But again, I'm not sure we should provide these methods,
> I have no idea if it worth the pain to have to implement it for all
> streams.

There's surprisingly little pain :)

Every parallel stream already has a spliterator() embedded in it; that's 
how you create a parallel stream.  If you have a trivial pipeline:

   Stream<T> pipe = foo.parallel();

the library can just return the spliterator provided when the stream was 
created.  (There are tools for turning various things like Iterable or 
Iterator into a (dumb) Spliterator, if that's all you have.)  If you 
have a nontrivial pipeline:

   Stream<T> pipe = foo.parallel().map(e -> 3);

then the library takes the base spliterator, and wraps it with one whose 
splitting methods just pass through to the underlying spliterator, and 
whose iterator method uses the wrapIterator methods of the op chain. 
Painless.


Where there is some pain is specifying it, and what the interactions are 
with other actions.  Such as, does calling (spl)iterator mean you can't 
call a terminal op?  What happens when you call iterator twice?  Do you 
get the same iterator?  What happens when you call iterator and then 
spliterator?  But, I think we have to spec these things anyway.