PROPOSAL: abstract enums

[Derek Foster]

Joe Darcy wrote:
>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

Joe, I am not sure you realize that I actually HAVE done serious research as to why enums were designed the way they were. I've read those documents already, and a lot of other ones besides. I just read them again now just to be sure I hadn't missed anything. Nonetheless, my research has so far not come up with evidence that the approach I have outlined in my proposal was seriously considered (or considered at all!) by the working group, and has produced zero instances of a technical argument as to why it wouldn't work or why it would be significantly difficult to implement, or would cause significant problems. Basically, the documents you have pointed me towards so far have not discussed my approach at all. The link above is no exception to this. It discusses the (lack of) merits of the extensible enums approach but is entirely silent on the approach suggested by my proposal.

If you have specific technical reasons why you think MY approach (as opposed to the extendable enums approach that is the only one discussed by all of the links you have sent out so far) won't work or would be difficult to implement, then please present them, so I can address them. My research so far has failed to turn up any such reasons. I have seen nobody claiming that lack of the ability to have abstract supertypes of enums is a GOOD thing, just that having concrete subtypes of them (as per the extendable enums approach) is clearly a BAD things.

I can speak from personal experience when I say that the lack of this feature in Java is both mysterious (since there seems no specific technical reason to forbid it, and it seems unnecessarily different from how classes work) and quite frustrating and time-consuming to work around. I mentioned some of those experiences in the overview of my proposal. Apparently Stephen has had similar experiences. Obviously, I was annoyed enough by them that I spent five hours researching the topic and writing up a proposal to fix the problem. I think that those two testimonials should count for something when considering what impact this problem has on developers.

Perhaps (although I have seen no documented evidence of this) the original working group DID carefully consider this exact feature and decided that lack of it wasn't likely to cause enough problems to justify the small effort required to implement it. Well, if that is true, then perhaps the real-world evidence of Stephen and I should be considered as evidence that that initial hypothesis was possibly incorrect and should be reevaluated in light of the new evidence.

Derek



-----Original Message-----
>From: Joe Darcy <Joe.Darcy at Sun.COM>
>Sent: Mar 31, 2009 12:05 AM
>To: Stephen Colebourne <scolebourne at joda.org>
>Cc: coin-dev at openjdk.java.net
>Subject: Re: PROPOSAL: abstract enums
>
>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
>