PROPOSAL: Abstract enums (version 2)

Howard Lovatt howard.lovatt at iee.org
Wed May 6 17:32:13 PDT 2009


Hi Derek,

Your proposal isn't as straight forward as you are making out, Joe
Darcy has summarised the issues nicely.

If we made Enum an interface and had the compiler synthesise the
required methods then this would allow any compatible class (see
below) to be a super class of an enum. IE a class declared using enum,
whether abstract enum or plain enum, would implicitly implement Enum,
implicitly have private constructors, and the compiler would add the
methods and fields that are currently in class Enum (including
valueOf). A compatible superclass would need to be compatible with
interface Enum and have an accessible no-args constructor. The no-args
constructor limitation of superclasses isn't strictly necessary, but
it simplifies the compiler (relaxing the no-args rule could be for
Java 8 :) ).

The tricky bit is method valueOf, because this method is static and
therefore can't be specified in an interface. As stated above this
method is added to enums and this will catch most uses of this method
in user code. However code that currently says Enum.valueOf( ... )
will break. To ease the transition an Enums, note s, class with a
static valueOf could be provided.

This is a simpler change, e.g. no change in meaning of abstract enum,
and also a more powerful change, i.e. any compatible class can be the
superclass. It is theoretically possible that this change would break
existing code, as outlined above, but in practice I doubt if much code
would actually be broken. Obviously one of the issues for an expert
group to study would be my claim, based on my own coding style, that
little code in practice would be broken.

  -- Howard.



More information about the coin-dev mailing list