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

[Brian Goetz]

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