Spliterator (original) (raw)

Brian Goetz brian.goetz at oracle.com
Wed Dec 19 06:19:06 PST 2012

There's no reason it can't be spec'ed and generalized to more than one subsequent split (and if an implementation doesn't want to promise that, return 1.) Sorry, I don't get this. Is the intent to be able to bypass a call to isSplittable across multiple calls to split?

That's not the goal, though that is an effect.

That is, do you need to replace:

while (s.isSplittable() && /* ... other conditions ...*/) ... s.split... with: for (int splits = s.getNaturalSlits();...) { if (!/* ... other conditions ...*/) break; ... s.split... } Or is there some other reason I'm not seeing?

We use split() to build a tree of splits; this is mirrored by a tree of FJTs. I use this information to determine when split() is creating a new level of the tree, and when it is creating a new sibling at the same level.

             T firstChild = makeChild(spliterator.split());
             setPendingCount(naturalSplits);
             numChildren = naturalSplits + 1;
             children = firstChild;
             T curChild = firstChild;
             for (int i=naturalSplits-1; i >= 0; i--) {
                 T newChild = makeChild((i > 0) ?

spliterator.split() : spliterator); curChild.nextSibling = newChild; curChild = newChild; } for (T child=children.nextSibling; child != null; child=child.nextSibling) child.fork();

             firstChild.compute();

(Or is getNaturalSplits a remnant from previous designs in split was not mutative and you could ask for multiple splits at once?)

You could think of it as an alternate way to do that, yes.

The point is: I see value to the possibility of arranging spliterators in other than a binary tree.

To be useful, the spec must imply that if isSplittable returns false the caller should not call split.

Agreed.

But we cannot say such things in an interface spec. The constraint that I listed makes it clear that looping calls to split that do not check isSplittable could infinitely loop.

Right. But if we s/isSplittable == false/getNaturalSplits == 0/, why don't we get that same promise?

I don't disagree with anything you're saying except the implicit assumption that no one would ever want to build other than a binary tree of splits. (And I don't understand what the split arity has to do with the other spec issue, and why they're being intertwined?)

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