Expected behavior of a Streams.cycled() instance - found issues and questions
peter.levart at gmail.com
Wed Oct 24 02:36:20 PDT 2012
On 10/23/2012 07:11 PM, Brian Goetz wrote:
>> >1) Should it be allowed (as it is now) to concat to the end of an
>> >infinite (cycled for example) stream?
> It doesn't seem so useful, but also such attempts to protect the user
> from themselves are also often counterproductive, especially if "known
> infinite" really means "probably infinite." For example, what about:
> infiniteStream.filter(t -> false)
> So the answer is "maybe, but maybe not."
"known infinite" vs. "probably infinite". "probably infinite" is more
useful. But the name is not exact.
Maybe the INFINITELY_SIZED flag should be renamed to INFINITELY_TIMED.
Meaning that evaluating the (whole) stream never completes. This implies
that the size is not known.
Streams.repeat(stream) is INFINITELY_TIMED (unless 'stream' knows it's
size and it is 0 in which case .repeat can optimize and return an empty
infinitelyTimedStream.filter(t -> false) is still INFINITELY_TIMED (and
the framework still can not know it's size)
sorting an INFINITELY_TIMED stream will always: either not complete or
throw OOME, so instead of exercising memory pressure to stop the
algorithm, framework could throw an exception (unless user actually
wanted to program an infinite loop - what a freak). The same goes with
groupBy. Uniq is different, at least the serial variant which is
pass-through and is useful when downstream only consumes a limited
number of elements, but the parallel Uniq will always: either not
complete or throw OOME.
On a second thought, I think that infinite loops should not be prevented
though. Someone might want to program termination logic by throwing an
exception (what a freak :-). As there is no .filterWhile(Predicate) or
such, this might be he's only choice...
More information about the lambda-dev