stream() / parallelStream() methods
Kevin Bourrillion
kevinb at google.com
Fri Feb 8 15:39:06 PST 2013
On Fri, Feb 8, 2013 at 3:32 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
Here's the other issue this raises.
>>
>> To my knowledge there's no Streamable<T> interface defined.
>>
>
> Right. Earlier drafts had one (ask Doug to recount the "OMG so many
> interfaces" horror of Iteration 2), and since then we've been working
> really hard to eliminate each incremental public type, as each adds API
> surface area. I think we've been really successful at this; I'd hate to
> slide backwards.
>
>
> Maybe it
>> wasn't needed; I'm not sure. But once Iterable looks like this, now
>> Iterable becomes the new Streamable. If you support a stream(), you'll
>> implement Iterable to expose that fact. This is a little bit weird.
>> I'm undecided on how big a problem it would be, but overall,
>> Streamable<T> seems like a pretty normal thing to have.
>>
>
> Leading question: if everything that is Iterable is effectively Streamable
> (because Iterable has a stream()) method, and everything Streamable is
> effectively Iterable (because you can turn a Spliterator into an Iterator),
> aren't they then the same abstraction?
>
Yes: just making sure we really want that.
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 :-))
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the lambda-libs-spec-observers
mailing list