parallelStream() methods (original) (raw)
Kevin Bourrillion kevinb at google.com
Fri Feb 8 15:39:06 PST 2013
- Previous message: stream() / parallelStream() methods
- Next message: stream() / parallelStream() methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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 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
- Previous message: stream() / parallelStream() methods
- Next message: stream() / parallelStream() methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list