stream() / parallelStream() methods

[Kevin Bourrillion]

Sure, sure: it's much more about perception than specific impediment to
usage.


On Fri, Feb 8, 2013 at 3:44 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> If I fail in my bid to kill parallelStream() then could we at least keep
>> it on Collection?  With Iterable already growing from 1 to 3 methods,
>> that one extra is pretty significant bulk.  (Still, let's kill it
>> entirely :-))
>>
>
> I'm not sure I get this "bulking" argument.
>
> The implementation on Iterable will be a default.
>
> Let's say you're implementing an Iterable.  There are two ends of the
> spectrum:
>
> 1.  You are building a high-performance data structure.  You are
> definitely going to want to create your own spliterators and offer the best
> parallel performance.  So you are happy to see parallelStream().
>
> 2.  You are wrapping some other aggregates that you just want to be
> Iterable, so you cobble together an Iterator from whatever you've got. In
> which case you're likely to take the default stream/parallelStream
> implementations.  So you don't care that Iterable has parallelStream.
>
> So at the ends, either you like it, or you're agnostic.  What's in the
> middle that's different?  I'm not seeing it.
>
>
>
>


-- 
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/33ba4805/attachment.html