Return types array/list/stream [was: API question for point lambdafication]
Brian Goetz
brian.goetz at oracle.com
Wed Feb 20 08:52:28 PST 2013
I don't want to risk taking it too in the other direction, but I do
think the points in favor of Stream are applicable in a lot of
situations. But as always, it requires some analysis about what you
expect people to DO with the result.
On 2/20/2013 11:46 AM, Michael Nascimento wrote:
> Given your reasoning, shouldn't the default be Stream from now on?
>
> Regards,
> Michael
>
> On Wed, Feb 20, 2013 at 1:35 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> My preference would be as folows:
>>> - only use array as a return type to match other methods in the same type
>>> - prefer List to Set or Collection
>>> - prefer Stream to Iterator and Enumeration (and probably Iterable)
>>> - prefer List to Stream for small/bounded data sets
>>>
>>> Thus, on the last point, I would argue that String.splitAsStream() is
>>> wrong, and should be String.splitToList(). (As a side note, with my
>>> general "arrays are bad" hat on, returning an array here was another
>>> bad choice)
>>>
>>> Users wanting a stream can easily get it from the list. The reverse is
>>> not so true, and almost certainly more wasteful.
>>
>> This ignores a significant consideration -- List requires buffering all
>> the matches before any work can be done, whereas Stream is lazy. What
>> if the List is potentially huge (or infinite)? What if you're only
>> going to look at the first few? What if producing elements is
>> expensive? What if you have an expensive operation to perform on the
>> results, and want to do so in parallel? In all of these cases,
>> preferring List over Stream gives up significant performance
>> opportunities. And, constructing lists is likely to be more expensive
>> than constructing streams.
>>
>> The argument that we should "prefer List to Stream because you can
>> always get a stream from a list" is too simplistic.
>>
>> Regex parsing is a good example of where you might want a stream rather
>> than a list, as you might well not consume all the matches.
>>
>>
More information about the lambda-dev
mailing list