PROPOSAL: abstract enums

[Joe Darcy]

Stephen Colebourne wrote:
> 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.


Even though lack of this feature admittedly makes writing certain APIs 
more difficult, that certainly does not necessarily imply a language 
change is an appropriate remedy.

[snip]

> The argument of "the original EG decided" is a poor one. By that 

The argument of "we can simply ignore the past" is a poor one as well.

However, I assume you are not putting forward such a naive justification 
for this change.

> 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'.

All the language changes occur in the context of what has gone before 
and what might come in the future.  Some changes have been deliberately 
deferred until more research could occur.  For example, some kind of 
generics were deliberately left out of Java 1.0 because it was 
determined an adequate version could not be designed and implemented in 
time.  Other changes have been decided against explicitly or implicitly; 
   Java explicitly decided against multiple inheritance of classes.

IMO the level of discourse on the list would be improved if more time 
was taken to research and understand why the previous language decisions 
  were made and the many trade offs involved.  For example, some of the 
rationale for enums is contained in the early draft documents of JSR 201:

     http://www.jcp.org/en/jsr/detail?id=201

A quote I came across doing background reading for Project Coin 
frequently comes to mind:

"If this book [Principles of Programming Languages] has convinced the 
reader that a programming language designer needs the expertise of a 
scientist, the precision of a mathematician, and the taste of an artist 
as well as the pragmatism of an engineer, then it has achieved one of 
its objectives."
--R. D. Tennent


-Joe