stream() / parallelStream() methods

[Kevin Bourrillion]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130208/2af636e9/attachment.html