PROPOSAL: Abstract enums (version 2)

[Howard Lovatt]

Joe,

Is it too late to submit a second abstract enum proposal, see Derek's
email below? The idea is that the expert group would evaluate both
proposals in parallel.

  -- Howard.

Derek Foster writes:
Hi, folks.

I think Howard's counterproposal might be interesting, if it were
fully fleshed out to the degree that my proposal is by now. I might
even prefer his to mine, if that were the case. However, it's hard to
evaluate in its current form. A lot of potential implementation
problems are currently being handwaved past -- a real proposal would
have to grapple with these and find specific answers to all of them:
Binary compatibility, serialization, how to handle Enum's static
methods, how to identify and what to do about inherited or overridden
methods that conflict with the current Enum's, how to reduce code
bloat in subtypes due to duplicate methods, etc.

My "abstract enums" proposal is an attempt to add abstract supertypes
to enums while changing as little as possible about how enums
currently work, so as to not disturb any existing code (serialization,
IDEs, etc.) that might depend on the current semantics and
implementation strategy. I went to quite some trouble to minimize the
scope of the changes to try to make the proposal small enough for
Project Coin and to minimize any disruption to the compiler or
libraries.

Howard's suggested counterproposal attempts to achieve a little bit
more (the ability for an enum and a non-enum to share a supertype) by
totally changing how enums are implemented. In particular, under
Howard's proposal, Enum becomes an interface, not an abstract
superclass, and its methods become duplicated in each leaf subclass
rather than inherited. Plus some changes would have to be made to the
compiler to hack in a way to still do things like
"Enum.valueOf(Foo.class, "bar")" (I don't buy Howard's argument that
we can just abandon backwards compatibility and encourage people to
migrate away from these static methods, although I think that this
"abstract class->interface" migration is a good argument for the
"static methods in interfaces" proposal that was put forth on the list
a while ago and (IIRC) already shot down. Possibly we could just hack
the compiler to treat "Enum.valueOf" as a special case and map the
method invocation to a different static method on another class in
java.lang, though.)

Still, overall, what Howard proposes is a pretty major change to how
enums of all kinds (not just abstract ones!) work. I'm not necessarily
opposed to it -- David raises some good points about its
applicability, and I can recall some times where I might have been
inclined to extend an enum from a non-enum abstract class for the
purpose of creating a singleton or a fixed-size set of them, if the
option had been available. Howard's approach would meet my abstract
enum needs as well as mine does, and has some other minor pluses, so
in that sense, I don't really care about which approach is taken... if
there aren't hidden "gotcha's" as far as implementation goes, which is
hard to tell at this level of detail.

If Howard wants to try 'fork'ing my proposal and modifying it to add a
parallel version of it implemented along the lines he suggests, I
won't mind (although Joe might, if he considers it a new (late)
proposal instead of a modification of an existing one). Ideally, the
two co-proposals would be considered in parallel. However, I'm not
currently planning to abandon my proposal's current implementation
approach in favor of Howard's unless I am convinced that Howard's has
a better chance of actually being selected by Sun -- which would imply
at the very least that it has been described in exacting detail and
that all implementation challenges have been identified and that
specific solutions for them are proposed, and have been vetted by the
Project Coin listmembers. (Is there still time to do this?
Questionable...)

This would have been a lot easier if a proposal along the lines of
what Howard is suggesting had been put forth before the cutoff
deadline for proposal submissions...

Derek