PROPOSAL: Abstract enums (version 2)

[Derek Foster]

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




-----Original Message-----
>From: David Walend <david at walend.net>
>Sent: May 17, 2009 7:45 PM
>To: coin-dev at openjdk.java.net
>Subject: Re: PROPOSAL: Abstract enums (version 2)
>
>
>On May 13, 2009, at 2:53 AM, coin-dev-request at openjdk.java.net wrote:
>> Date: Wed, 13 May 2009 10:35:17 +1000
>> From: Howard Lovatt <howard.lovatt at iee.org>
>> Subject: Re: PROPOSAL: Abstract enums (version 2)
>>
>> On a pragmatic point, I doubt if the proposal will go anywhere since
>> no one is supporting it except me :( The point you make about wanting
>> to change from a singleton to a number of instances in the future
>> might be valid, but I haven't personally had this problem in using
>> Scala and I haven't heard of others having problems in Scala.
>>
>> The main enhancement I would find useful is to be able to extend an
>> arbitrary abstract class when making an enum. The present proposal of
>> a special abstract enum wouldn't help my use cases much. Therefore I
>> don't thing the Singleton variation is that important.
>
>
>Howard,
>
>I'll speak for enumerations extending abstract classes. It comes up  
>every forth project or so for me; machine-readable JMX notifications  
>come to mind. A lot of general purpose abstract classes should only be  
>used certain ways within a particular context. Sometimes those ways  
>fit an enum well. With the current limitation, I have to extend the  
>abstract class, then create an enum full of pass-through methods. It's  
>uninteresting boilerplate, and labor to maintain. I'd use enums this  
>way occasionally if it were part of JDK7.
>
>Dave
>