On 08/12/15 00:19, Stuart Marks wrote:
Hi Maurizio,
Well, maybe we should add five more overloads to EnumSet.of()? (Only
slightly joking here.)
Setting aside the number of overloads, it would add N more overloads
to Set.of(). I guess the erasure of <Z extends Enum<Z>> would be Enum,
so there wouldn't be any overload ambiguity....
right - no ambiguity
To me the question here is whether this adds sufficient value. The
advantage is that one could write
Set.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE)
instead of
EnumSet.of(MyEnum.ONE, MyEnum.TWO, MyEnum.THREE)
and get an optimized EnumSet instead of a Set that contains object
references. Is it worth it?
I'm not too worried about the fact that typing 'EnumSet' is more verbose
than just 'Set', obviously; but it would seem reasonable to try (within
reasonable bounds) to provide uniform way to create collections and a
smooth user experience.
I think with the current status quo, we have that:
Set.of(A, B, C) != EnumSet.of(A, B, C)
and that's surprising, IMHO. At the same time I notice that, even with
the overload I suggest, they would still be different beasts, as one
would be mutable, while the other would not.
That said, I think we should aim for an API where such bad surprises are
avoided (why is my enumset so slow? Ah - it's not an enumset because I
used the wrong XYZ.of method); unfortunately I don't have a good
suggestion on how to get there :-( (which might mean that what you did
is correct :-) )
Maurizio
Presumably this would result in an instance of an immutable EnumSet.
Does this case come up that often?
s'marks
On 12/4/15 2:22 PM, Maurizio Cimadamore wrote:
Hi Stuart
small question: I find it a bit odd that EnumSet has max 5
parameters, while Set
has more than that.
Also, would it be possible, maybe to add overloads to Set that
specifically
works on Enum constants?
<Z extends Enum<Z>> of(Z z1, Z z2) { ... }
This would give you a way to call Set.of and get different answers
based on the
static type of the arguments passed in - and we could deprecate the
of method in
EnumSet?
Too subtle/magic?
Maurizio
On 02/12/15 02:35, Stuart Marks wrote:
Hi all,
Thanks for the previous round of review comments. Here's an updated
API and
implementation for review.
I've run specdiff with the --hu ("hide unchanged") option, so only
the bits of
the specification that have changed are shown. As before, though,
please
ignore the spurious change to EnumSet caused by a javadoc bug.
API changes:
- add clarifying notes on immutability
- remove wording that implied creation of new objects
- add "value-based" disclaimers
- add ordering specification for List and non-ordering disclaimers
for Set and Map
- clarify that Map.ofEntries() doesn't store the Map.Entry objects,
instead
it extracts keys and values
- Map.Entry instances returned from Map.entry() are *not* serializable
Other:
- markup cleanups
- small implementation cleanups
JEP:
http://openjdk.java.net/jeps/269
API spec (basically List, Map, and Set):
http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/
Specdiff:
http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/
Thanks,
s'marks
