Iterable/Iterator.stream()

[Remi Forax]

On 03/24/2013 10:51 PM, Brian Goetz wrote:
> I think Sam's point was that there are plenty of library classes that give you an Iterator but don't let you necessarily write your own spliterator.  So all you can do is call stream(spliteratorUnknownSize(iterator)).  Sam is suggesting that we define Iterator.stream() to do that for you.

The problem is how to pass the Spliterator flags.

>
> I would like to keep the stream() and spliterator() methods as being for library writers / advanced users.

Given that writing a Spliterator is easier than writing an Iterator,
I would prefer to just write a Spliterator instead of an Iterator 
(Iterator is so 90s :)

Rémi

>
> On Mar 24, 2013, at 5:44 PM, Remi Forax wrote:
>
>> On 03/24/2013 08:32 PM, Sam Pullara wrote:
>>> I was working with Brian on seeing how limit/substream
>>> functionality[1] might be implemented and he suggested conversion to
>>> Iterator was the right way to go about it. I had thought about that
>>> solution but didn't find any obvious way to take an iterator and turn
>>> it into a stream. It turns out it is in there, you just need to first
>>> convert the iterator to a spliterator and then convert the spliterator
>>> to a stream. So this brings me to revisit the whether we should have
>>> these hanging off one of Iterable/Iterator directly or both.
>>>
>>> My suggestion is to at least have it on Iterator so you can move
>>> cleanly between the two worlds and it would also be easily
>>> discoverable rather than having to do:
>>>
>>> Streams.stream(Spliterators.spliteratorUnknownSize(iterator,
>>> Spliterator.ORDERED))
>>>
>>> Sam
>>>
>>> [1] https://github.com/spullara/java-future-jdk8/blob/master/src/main/java/spullara/util/Limiter.java
>> It's not really a good sign of the heath of the API.
>>
>> it seems that for a lot of problems there is no way to write a good Spliterator directly,
>> i.e. it's better to write an Iterator and let the JDK create the Spliterator around it,
>>
>> Rémi
>>