PROPOSAL: abstract enums

Stephen Colebourne scolebourne at joda.org
Mon Mar 30 17:13:53 PDT 2009


Joseph D. Darcy wrote:
> Of the extensible and non-extensible version of enum pattern, the JSR 
> 201 expert group chose the non-extensible variant and many other 
> decisions and details of the original enum design flow from that 
> fundamental decision.  Revisiting that decision now is impractical.
> 
> Additionally, some of the advantages of extensible enums can be had by 
> making different enum classes implement a common interface; for some 
> discussion of that general pattern see
> 
>     "Mixing-in an Enum"
>     http://blogs.sun.com/darcy/entry/enums_and_mixins
> 
> as well as an item in the 2nd edition of "Effective Java."

The lack of abstract enums (where the superclass merely contains code, 
not enum constants) has definitely had a negative impact on the 
usefulness of the feature. JSR-310 will be significantly worse as an 
implementation as a result of this omission.

Further, the addition of abstract enums like this adds to the syntactic 
power of the language in a way few other Coin proposals do. This is 
because some of the use cases are simply impractical to do without the 
feature, due to the vast amount of repetitive boilerplate code that 
would be required.

('Abstract enums' are a request for implementation inheritence for 
enums, without which certain things are nigh on impossible now. The only 
alternative I can think of that is adding a language level 'delegation' 
concept, effectively allowing implementation by composition at the 
language level. And, given abstract enums likely interaction with 
annotations, delegation isn't a full answer)

So, while I understand that this isn't a Coin feature (type change 
effectively), it really should not be dismissed so easily. This is 
something that can and should be open be revisited now we have 
experience with enums.

The argument of "the original EG decided" is a poor one. By that 
argument, we should not make any changes to Java, and leave it as in 
v1.0. As such, I request that you consider merit, not an arbitrary 'it 
changed recently'.

Stephen




More information about the coin-dev mailing list