Spliterator flags as enum (was Initial java.util.Spliterator putback)
tim at peierls.net
Fri Mar 29 09:05:40 PDT 2013
Yes, I'd make the same argument for ForkJoinTask, but don't (in turn) lose
sight of what that argument is. I'm *not* saying "int flags always bad;
enums always good". I *am* saying that the docs should take care to explain
why a popularly disavowed practice is being tolerated, even in an API that
only a few people will have to use. And that the explanation should be
honest and not a fancy paraphrase of "It's good enough for an expert-level
API, so we didn't bother to look seriously at alternatives."
I'm not even trying to argue that the popular thinking is correct, just
that it is popular enough to make it urgent that design decisions that run
counter to it need to be explained carefully.
On Fri, Mar 29, 2013 at 11:40 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
> Let's not lose sight of the fact that this is not a "for everyone" class
> like ArrayList or Pattern. This is low-level machinery for supporting
> parallel operations. If we've done our job correctly, the vast majority of
> users will never see Spliterator. Imagine this were part of the FJ
> implementation (spliterators exist in 1:1 correspondence with FJTasks.)
> Would you be making this same argument if this were ForkJoinTask?
> On Mar 29, 2013, at 8:25 AM, Tim Peierls wrote:
> On Fri, Mar 29, 2013 at 10:53 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> But really, the painfulness quotient is equally important.
>> We'd need to create immutableEnumSet class, and another class
>> that can arbitrarily extend the Spliterator's enums with
>> other control flags, all for the sake of arriving at an API
>> that seems less clear and less easy to use than what we have.
> That API doesn't exist, so it's not really fair to say that it seems less
> clear and easy to use. As far as I can see in the common discussions, no
> one has seriously explored any alternatives.
> The presence of such flags in a Java 8 API would (and should) raise a lot
> of eyebrows, because it goes against what people have been told for well
> over a decade. If it's adopted as is, there had better be a good
> explanation for doc readers of why alternatives were rejected. "We were
> comfortable with int flags and nothing else significantly better suggested
> itself" won't cut it. "We know int flags aren't great for an API, but we
> tried very hard to find better alternatives, to no avail" would (if it were
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts