easier work with collections: default Stream.toList?

[Zhong Yu]

By the same reasoning, List should not be used in any public API ever:)

The proposed toList() method is obviously a backward looking API to
help Stream to interact with legacy code/mindset. It is "not pure",
but it is very useful.

Another use case to consider: in a new API method, I could return a
Stream or a List. I prefer Stream, but I suspect that a lot of users
would rather see a List instead, which makes me really hesitant to
return a Stream. If Stream had a toList() method, and assume
list.stream().toList() is very efficient, then there's no problem to
return a Stream here.

Zhong Yu


On Wed, Oct 2, 2013 at 4:11 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Oct 2, 2013, at 10:18 AM, Gernot Neppert <mcnepp02 at googlemail.com> wrote:
>> Thumbs up for 'toList()'!
>>
>> In our home-brewn Streaming framework, 'toList()' is the terminal operation
>> in the vast majority of all usecases. We have a more generic method
>> 'into(Collection)' also, but we explicitly added 'toList()' because it was
>> so frequent!
>>
>
> Thanks, that anecdotally confirms what i suspected.
>
>
>> I have to admit I don't understand the opponents' argument  'adding
>> toList() ties the Streaming API to the Collections API'. Both
>> java.util.Collection and java.util.streams.* will be part of the JDK for
>> years to come. It's not as if we were to abandon the Collections framework
>> in the foreseeable future, right?
>> (Like every API, it  has it's quirks, but it's far from 'bad')
>>
>
> It means
>
> - other implementations of Stream, using a different collections, are also tied to the current JDK collections; and
>
> - in the future there may be better or alternative collections.
>
> If we ever get to the point of including persistent collections there is likely to be a different set of collectors that could be used. Persistent collections would be very handy for parallel reduction since they will most likely be more efficient for merging (although we can and probably should improve our current implementation of list merging and use an internal chunked list representation to avoid copying the right side into the left side).
>
> Paul.
>
>
>