stream() / parallelStream() methods

[Joe Bowbeer]

This concern over reuse rings a bell.  Are these the concerns that led us
*not* to burden Iterable with these methods?

We haven't talked about ISE in months, so we did something right :)


On Fri, Feb 8, 2013 at 3:23 PM, Kevin Bourrillion <kevinb at google.com> wrote:

> Can we make our best attempt to specify Iterable.stream() better than
> Iterable.iterator() was?
>
> I haven't worked out how to *say* this yet, but the idea is:
>
> - If at all possible to ensure that each call to stream() returns an
> actual working and *independent* stream, you really really should do that.
> - If that's just not possible, the second call to stream() really really
> should throw ISE.
>
> (Yes, I do realize most Iterables by far will just inherit stream(), so it
> will only be as repeat-usable as iterator() is.)
>
>
> On Fri, Feb 8, 2013 at 3:20 PM, Kevin Bourrillion <kevinb at google.com>wrote:
>
>> 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
>>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>