Spliterator (original) (raw)

Doug Lea dl at cs.oswego.edu
Tue Nov 27 17:23:59 PST 2012

... and back to:

On 11/19/12 17:11, Brian Goetz wrote:

Good question, and related to the concurrent discussion about Sized. If the Sized/LongSized strategy seems viable, it becomes more practical to make all the sizes here long. I'd prefer to make all the sizes long, but only if we can make some progress on a migration path from 32 to 64 bit collections.

(See previous post.) Lets assume long for ...

I guess I didn't think these would be burdensome to write?

My main point was that these methods are only sensible if people are told the precise split strategy, which is subject to change. It would be better to have methods that just provide properties that can be used as hints rather than hinting-methods.

Here's shot:

Heuristics: getSizeIfKnown // default = -1 estimateSize // default -1

replace with: long getMinimumElementCount(); // default 0 long getMaximumElementCount(); // default MAX_VALUE

getNaturalSplits // can always return 1 (means binary split)

YAGNI: anyone creating a collection for which splitting by two is infeasible will very likely end up writing all the stream ops for it anyway, so why bother?

isPredictableSplits // can always return false

Is there any potential use that is not covered by knowing min/max of current and subtask splits?

-Doug

More information about the lambda-libs-spec-observers mailing list