Please rethink extended enums inclusion

Jose Antonio Illescas Del Olmo jantonio.illescas at rbcdexia-is.es
Fri Oct 7 08:35:34 PDT 2011


On 07/10/2011 17:24, Henri Gerrits wrote:
> 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.
>
The enum is my "translator",

    · On some cases/enums I persist the code on database: our "new 
application" accesss to legacy tables used by other applications, and 
persists the enum code


>>>> /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.
>
You are right.


> Best regards,
>   
> Henri
>




More information about the coin-dev mailing list