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

Remi Forax forax at univ-mlv.fr
Fri Nov 16 12:51:00 PST 2012


On 11/16/2012 05:51 PM, Brian Goetz wrote:

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

yes, asking for an iterator is a terminal op too.

What happens when you call iterator twice?

you can't. see above :)

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.

again, when you call a terminal method, it freezes the whole streams chain back to the stream created with Streamable.stream(), so you can't call a terminal ops twice otherwise you have to specify all combinations by example what if I call findFirst() then forEach().

Rémi



More information about the lambda-libs-spec-observers mailing list