Base class for spliterators. Iteration starts at a given
origin and continues up to but not including a given fence (or
null for end). At top-level, for ascending cases, the first
split uses the root as left-fence/right-origin. From there,
right-hand splits replace the current fence with its left
child, also serving as origin for the split-off spliterator.
Left-hands are symmetric. Descending versions place the origin
at the end and invert ascending split rules. This base class
is non-commital about directionality, or whether the top-level
spliterator covers the whole tree. This means that the actual
split mechanics are located in subclasses. Some of the subclass
trySplit methods are identical (except for return types), but
not nicely factorable.
Currently, subclass versions exist only for the full map
(including descending keys via its descendingMap). Others are
possible but currently not worthwhile because submaps require
O(n) computations to determine size, which substantially limits
potential speed-ups of using custom Spliterators versus default
mechanics.
To boostrap initialization, external constructors use
negative size estimates: -1 for ascend, -2 for descend.
Base class for spliterators. Iteration starts at a given origin and continues up to but not including a given fence (or null for end). At top-level, for ascending cases, the first split uses the root as left-fence/right-origin. From there, right-hand splits replace the current fence with its left child, also serving as origin for the split-off spliterator. Left-hands are symmetric. Descending versions place the origin at the end and invert ascending split rules. This base class is non-commital about directionality, or whether the top-level spliterator covers the whole tree. This means that the actual split mechanics are located in subclasses. Some of the subclass trySplit methods are identical (except for return types), but not nicely factorable.
Currently, subclass versions exist only for the full map (including descending keys via its descendingMap). Others are possible but currently not worthwhile because submaps require O(n) computations to determine size, which substantially limits potential speed-ups of using custom Spliterators versus default mechanics.
To boostrap initialization, external constructors use negative size estimates: -1 for ascend, -2 for descend.