Iterable.stream()

[Kevin Bourrillion]

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> wrote:

> Currently we define stream() and parallelStream() on Collection, with
> defaults like:
>
>     default Stream<E> 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<Path>) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130221/4303fd17/attachment.html