On 03/28/13 14:52, Joshua Bloch wrote:
Doug,
I don't get it. You can set and unset flags on your own EnumSet. Why isn't that
sufficient?
There are a lot of problems. First, even
though most spliterators will return the same set of
characteristics each time, you can't just create one static one:
class MySpliterator { ...
static final EnumSet<Characteristics> cs = EnumSet.of(...);
EnumSet<Characteristics> characteristics() return cs; }
}
... because you cannot risk that no one will modify.
Second, when inside streams, you'd have to create a new EnumSet
Object across each stage, that somehow secretly extends the
public Characteristics with non-public internal control flags.
Which means either some slow conversion table or grabbing
private EnumSet internals.
So it is both slow and painful. I tried to make it less so,
knowing that people sometimes react hostilely to plain bit
sets. But I'm sure that the current scheme is better than all
I tried. (Ditto for Brian Goetz and Paul Sandoz).
In fact, I think the current scheme is sorta nice in
an absolute sense.
-Doug
Josh
On Thu, Mar 28, 2013 at 11:45 AM, Doug Lea <[email protected]
<mailto:[email protected]>> wrote:
On 03/28/13 13:18, Tim Peierls wrote:
I can't find a discussion of why Spliterator flags are ints rather than
enum.
We started out with enums on (my) initial Spliterator side vs
control flags internal to streams. The we had to somehow
mesh these to work together. On the stream side, you need
to set and unset various bits across stages. Clearly
you can't do that to someone's EnumSet -- they will not expect
you to modify it, but enforcing this makes it both unwieldy and
sleaze-inducing (we'd have to grab underlying representation from
EnumSet).
Another way of saying this is that we needed an efficient
propagate-by-value small-N bit set mechanism, and the only candidate
was the traditional one. This amounts to the same reason
that nio "interest" flags are done the same way.
-Doug
