Sets.immutableEnumSet() or ImmutableEnumSet.of()?

[GoogleCodeExporter]

I think there is a massive inconsistency between Sets.immutableEnumSet and 
every other way of creating immutable sets.  Is it worth creating a public 
ImmutableEnumSet class?  What about just alternate factory methods in 
ImmutableSet?

Impl-wise it could get extremely ugly.

Original issue reported on code.google.com by kevin...@gmail.com on 30 Oct 2009 at 8:10

[GoogleCodeExporter]

Downsides to public ImmutableEnumSet:

1) Currently it is declared as ImmutableEnumSet<E>, rather than 
ImmutableEnumSet<E
extends Enum<E>>, to keep GWT from generating serialization code for every 
available
enum.  It's not clear to be how bad the less-strict-than-necessary type 
parameter
actually is, since we can restrict the types that are valid to create through 
the
static factory methods we provide.

2) We can't fauxveride ImmutableSet.of() with anything useful.  It would have to
throw an exception.  More generally, "fauxverides in general."

Downsides to ImmutableSet.enumSetOf():

1) ImmutableSortedSet will inherit it.

I can't imagine declaring many fields/variable as ImmutableEnumSet, anyway, so 
the
only significant advantage in my mind to that approach is consistency.  (And of
course ImmutableSet.enumSetOf() doesn't quite provide that.)

Original comment by cpov...@google.com on 30 Oct 2009 at 8:23

[GoogleCodeExporter]

The type returned by ImmutableEnumSet.of() would not have to be 
ImmutableEnumSet; it 
can be some other package-private implementation class. That should take care 
of the 
first (1) above.

As for your _other_ (1), it could be there's no problem with ImmutableSortedSet 
inheriting it. But,

I think we should just live with this inconsistency as being an imperfection 
that 
happened because we didn't have infinite time to spend dithering over things 
like 
this. ok?

Original comment by kevin...@gmail.com on 2 Nov 2009 at 10:19

• Changed state: WontFix