Loose end: spliterator() and stream() methods on Iterable

[Brian Goetz]

Any comments on this spec?  (We can improve to a late-binding 
spliterator as an implementation detail later.)  If no other comments 
then I'll treat this loose end as tied off.

     /**
      * Creates a {@link Spliterator} over the elements described by this
      * {@code Iterable}.
      *
      * @implNote
      * <p>The default implementation should usually be overridden.  The
      * spliterator returned by the default implementation has poor 
splitting
      * characteristics, is unsized, does not report any other spliterator
      * characteristics, and is <em><a 
href="Spliterator.html#binding">early-binding</a></em>.
      * Implementing classes can nearly always provide a better 
implementation.
      * The returned spliterator inherits the <em>fail-fast</em> 
properties of the
      * collection's iterator.
      *
      * @return a {@code Spliterator} over the elements described by this
      * {@code Iterable}.
      * @since 1.8
      */
     default Spliterator<T> spliterator() {
         return Spliterators.spliteratorUnknownSize(iterator(), 0);
     }



On 6/25/2013 12:38 PM, Tim Peierls wrote:
> Not denying the badness of the default implementation, but could it be
> improved (very slightly) by defining and then using a variant of
> spliteratorUnknownSize that takes a Supplier<Iterator> rather than an
> Iterator? Only relevant if you were looking to tip the scales.
>
> --tim
>
> On Tue, Jun 25, 2013 at 11:27 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     As I try to specify even this small addition, I'm still not sure :(
>
>     The default implementation -- which is just
>
>        return Spliterators.__spliteratorUnknownSize(__iterator(), 0);
>
>     should almost always be overriden.  It has crappy parallelism,
>     doesn't know its size, doesn't know any other spliterator
>     characteristics, and is early-binding -- the "grand slam" of bad
>     spliterators.
>
>     The downside is that people will not override spliterator() and
>     result in bad streams.  The upside is that then Iterable *has* a
>     spliterator() method, which reduces the effort for *clients* to make
>     streams out of Iterables.
>
>     Here's what I've got so far:
>
>          /**
>           * Creates a {@link Spliterator} over the elements described by
>     this
>           * {@code Iterable}.
>           *
>           * @implSpec
>           * <p>The default implementation should almost always be
>     overridden.  The
>           * spliterator returned by the default implementation has poor
>     splitting
>           * characteristics, is unsized (and does not report any other
>     spliterator
>           * characteristics), and is <em><a
>     href="Spliterator.html#__binding">early-binding</a></__em>.
>           * Implementating classes can nearly always provide a better
>     implementation.
>           * The returned spliterator inherits the <em>fail-fast</em>
>     properties of the
>           * collection's iterator.
>           *
>           * @return a {@code Spliterator} over the elements described by
>     this
>           * {@code Iterable}.
>           * @since 1.8
>           */
>          default Spliterator<T> spliterator() {
>              return Spliterators.__spliteratorUnknownSize(__iterator(), 0);
>
>          }
>
>
>
>     On 6/25/2013 6:39 AM, Paul Sandoz wrote:
>
>
>         On Jun 24, 2013, at 11:41 PM, Remi Forax <forax at univ-mlv.fr
>         <mailto:forax at univ-mlv.fr>> wrote:
>
>             On 06/24/2013 09:40 PM, Brian Goetz wrote:
>
>                 After further thought, I think what this means is that
>                 we can move spliterator() up to Iterable, but not
>                 stream().  The reason for this is that some classes that
>                 implement Iterable<Integer> might prefer that their
>                 stream() method return an IntStream, not be forced into
>                 a Stream<Integer>.  So putting stream() too high up in
>                 the hierarchy forecloses on this.
>
>
>             I agree,
>
>
>         +1
>
>         Paul.
>
>
>             Spliterator.OfInt is a Spliterator but IntStream is not a
>             Stream.
>
>             Rémi
>
>