stream() / parallelStream() methods
Kevin Bourrillion
kevinb at google.com
Fri Feb 8 15:20:44 PST 2013
Yeah, I think we have little choice but to do this. It makes sense, and
without it, Guava will just end up having to offer a static helper method
to return (iterable instanceof Collection) ? ((Collection)
iterable).stream() :
Streams.stream(Streams.spliteratorUnknownSize(iterable.iterator()), 0).
Blech.
(Tangentially, I would really love to drop parallelStream() and let people
call stream().parallel(). But I haven't managed to scour the archives to
find if that argument's already suitably played out.)
On Fri, Feb 8, 2013 at 2:30 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Currently, we define stream() and parallelStream() on Collection, with
> default of:
>
> default Stream<E> stream() {
> return Streams.stream(() -> Streams.spliterator(iterator()**,
> size(), Spliterator.SIZED), Spliterator.SIZED);
> }
>
> default Stream<E> parallelStream() {
> return stream().parallel();
> }
>
> So the default behavior is "get an Iterator, turn it into a Spliterator,
> and turn that into a Stream." Then the specific Collection classes
> generally override it, providing better Spliterator implementations and
> more precise flag sets.
>
>
> Several people have requested moving stream/parallelStream up to Iterable,
> on the theory that (a) the default implementations that would live there
> are not terrible (only difference between that and Collection default is
> Iterable doesn't know size()), (b) Collection could still override with the
> size-injecting version, and (c) a lot of APIs are designed to return
> Iterable as the "least common denominator" aggregate, and being able to
> stream them would be useful. I don't see any problem with moving these
> methods up to Iterable.
>
> Any objections?
>
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130208/e6cb1835/attachment.html
More information about the lambda-libs-spec-experts
mailing list