brian.goetz at oracle.com
Sun Mar 24 14:51:49 PDT 2013
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.
I would like to keep the stream() and spliterator() methods as being for library writers / advanced users.
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 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:
>>  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,
More information about the lambda-libs-spec-experts