Spliterator

Doug Lea dl at cs.oswego.edu
Wed Dec 19 05:37:39 PST 2012


On 12/18/12 15:00, Brian Goetz wrote:
>>
>> 2. Because split() is stateful, it is unclear at
>> best what a return value > 1 for getNaturalSplits
>> might mean? All the child splits and their descendents?
>> Only the next #getNaturalSplits calls?
>> Flailing around left me with the conclusion that
>> the only sensible way to spec this is to rename as
>> boolean isSplittable(), thus clearly referring only to the
>> next call to split.
>
> I appreciate calling attention to the spec hole here, but I think this specific
> mitigation suggestion throws the bath toys out with the bathwater.
> Specifically, the boolean-vs-int return.  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 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?

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

>
> First, getNaturalSplits is purely advisory, since you can always return an empty
> spliterator from split().

To be useful, the spec must imply that if isSplittable returns false
the caller should not call split. 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.

>>      /**
>>       * Returns {@code false} if an invocation of {@code split()} is
>>       * guaranteed to return an empty Spliterator. Otherwise the method
>>       * implementation may choose a return value based on data
>>       * structure constraints and efficiency considerations.
>>       */
>>      boolean isSplittable();
>



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