PROPOSAL: Abstract enums (version 2)

[Bruce Chapman]

snip
> shall be modified to read:
>
> "A non-abstract enum type named E has a superclass (either direct or indirect via one or more abstract enums) of Enum<E>."
>
>
>   
If a non abstract enum E extends an abstract one, and E
has a superclass of Enum<E>   (as opposed to Enum<? super E>) , then the 
abstract one MUST have a type parameter to make that all happen.



abstract enum Super<T extends Super<T>> { ... }

enum E extends Super<E> { ... }



Should this type parameter be explicit or implicit? - guess since enums 
have an explicit extends, abstract ones could have an explicit type 
parameter.

your compilation section chooses implicit and says

abstract enum Foo {
   ,,,
}

shall be desugared to code resembling:

@AbstractEnum
 abstract class Foo<E extends Enum<E>> extends Enum<E> {


But I think it should be

abstract class Foo<E extends Foo<E>> extends Enum<E> {




re @AbstractAnnotation

I think you are confusing annotations in source files, with byte code 
annotations which are different. I don't think you'd need a new 
annotation (of either sort) because the bytecode for an abstract enum 
could have both the normal abstract annotation/modifier, and the 
existing enum one, allowing the compiler to correctly determine that it 
was in fact an abstract enum.


lastly,

Could the abstract enum have type parameters, such that declared methods 
were type polymorphic? (You enum for database table columns comes to 
mind here) and if so, could the methods be abstract thereby forcing the 
concrete enum to implement it?  The basic argument here is that if you 
are fixing enums to be consistent with the rest of the language in terms 
of inheritance, then maybe you should be in terms of type polymorphism 
as well. If you did, it would put a different slant on the 
implicit/explicit type parameter issue discussed above.

Other than those issues, this proposal is looking good by me.


Bruce