Please rethink extended enums inclusion

[Henri Gerrits]

From: Jose Antonio Illescas Del Olmo <jantonio.illescas at rbcdexia-is.es>
>To: Henri Gerrits <henrigerrits at yahoo.com>
>Cc: "coin-dev at openjdk.java.net" <coin-dev at openjdk.java.net>
>Sent: Friday, October 7, 2011 9:18 AM
>Subject: Re: Please rethink extended enums inclusion
>
>
>On 07/10/2011 14:32, Henri Gerrits wrote: 
>Hi Jose Antonio,
>> 
>>I have some issues with your proposal:
>> 
>>1. Inserting a superclass with new methods might break many existing enums
>
>Why? I decide when extends from custom abstract enum (checking that works fine) other enums (extends from "standard" enum) and works as ever.
 
I misunderstood - my mistake.
 
>
>2. Why do you need a code field? The name() method already returns a unique value.  The static valueOf() method can then be used instead of your fromCode() method.  I don't think caching makes much sense with enums, since the number of possible values are usually fairly small
>
>We have many communications with other finantial entities that use "standard protocols" with custom codes, while our application use descriptive enum names (on enums maps this relation between enums and codes).
>
>Our enums can parse from "standard codes" to enums and viceversa.
 
OK.  I don't know the details of your application but you might want to decouple the external protocol codes from your business code.  Maybe you can add simple "translator" classes used only in your interfaces with the external entities.

>>>/Abstract enums with Generic support reduce dramatically the code of 
>>>enums, see next code that use abstract enums:
>>>/
>>>*public enum Type extends MyAbstractEnum<String> {
>>>
>>>      ONE("01), TWO("03"), THREE("03"), ...;
>>>
>>>      private Type(String code) {
>>>          super(code);
>>>      }
>>>  }*
>>>
 
I think that should read:
 
  public enum Type extends MyAbstractEnum<String, Type> {
 
because you need the subclass type ("Type") for the in() method in MyAbstractEnum.
 
Best regards,
 
Henri