Spliterator

[Doug Lea]

... 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