Iterable.stream()

[Remi Forax]

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