Iterable.stream() (original) (raw)

Remi Forax forax at univ-mlv.fr
Thu Feb 21 11:33:37 PST 2013

On 02/21/2013 05:41 PM, Kevin Bourrillion wrote:

On Thu, Feb 21, 2013 at 8:14 AM, Joe Bowbeer <joe.bowbeer at gmail.com_ _<mailto:joe.bowbeer at gmail.com>> wrote:

Is this something we should address? There was no discussion about this last time. I still think it is. It's true that anyone who inherits the /default /stream() will get one that's only as good as their (possibly lousy) iterator always is, but that's the best we can do.

We provide a way to get a Spliterator from an Iterator and a Stream from a Spliterator, so we already provide a way to get a Stream from an Iterable but with no way to get a better stream if the Iterable is a Collection. so Iterable should have a method stream(), default methods are virtual exactly for that case.

Rémi

On Feb 21, 2013 8:07 AM, "Kevin Bourrillion" <kevinb at google.com_ _<mailto:kevinb at google.com>> wrote: 1. Yes please. 2. And this time I won't hijack the thread.

On Thu, Feb 21, 2013 at 7:44 AM, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote: Currently we define stream() and parallelStream() on Collection, with defaults like: default Stream stream() { return Streams.stream( () -> Streams.spliterator(iterator(), size(), Spliterator.SIZED), Spliterator.SIZED); } In other words, if a Collection does not override stream(), it gets the stream based on the iterator. It has been suggested that we could move stream/parallelStream() up to Iterable. They could use an almost identical default, except that they don't know the SIZED flag. (The default in Collection would stay, so existing inheritors of the Collection default wouldn't see any difference. (This is why default methods are virtual.)) Several people have asked why not move these to Iterable, since some APIs return "Iterable" as a least-common-denominator aggregate type, and this would allow those APIs to participate in the stream fun. There are also a handful of other types that implement Iterable, such as Path (Iterable) and DirectoryStream (where we'd added an entries() method, but that would just then become stream()). The sole downside is that it creates (yet another) external dependency from java.lang.Iterable -- now to java.util.stream. Thoughts?

-- Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com <mailto:kevinb at google.com> -- Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com <mailto:kevinb at google.com>

More information about the lambda-libs-spec-observers mailing list