Please rethink extended enums inclusion

Llewellyn Falco isidore at
Fri Oct 7 07:26:05 PDT 2011

I *really* think that changing enum is a bad idea. It is one of the things java has done right and better than anyone else.

However, I am once again struck at how extension methods would help in this situation. 

Just to be clear. I mean c#/ruby extension methods where you can externally extend an object you don't control, as opposed to defender methods where you can put default method on interfaces you do control.

Sent from my iPad

On Oct 7, 2011, at 6:34 AM, Jose Antonio Illescas Del Olmo <jantonio.illescas at> wrote:

> On 07/10/2011 14:38, Tom 
>> On 07/10/2011 12:34, Jose Antonio Illescas Del Olmo wrote:
>>> Now we have hundred of enums on our project (finantial application with
>>> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>>>      public enum Type {
>> [...]
>>>         public void setCode(String code) {
>>>             this.code = code;
>> I have to point out that mutable enums, or other statics, is generally a
>> *really* bad idea. (Also a non-null check here wouldn't go amiss.)
> Sorry, I don't understand you. Where is the mutable enums that you say?
>> It seems what we want here is a mutable Map<String,E extends Enum<E>>,
>> which is easy enough.
>>> **      public static Type fromCode(String code) {
>> Your inheritance wont work here. not unless you do something really dodgy.
> It's true, I really need next method on MyAbstractEnum:
>     public static <T extends Enum<T>> T fromCode(Class<T> enumType, 
> String code)  // similar to JDK Enum.valueOf(Class<T>, String) method
> and call from my Concrete enum:
>   public static Type fromCode(String code) {
>      return fromCode(Type.class, code);
>   }
>>> **      public boolean in(Type... types) {  // IMO all enums must have
>>> this method
>>>             if (types == null) return false;
>>>             for(Type type: types) {
>>>                if (this == type) return true;
>>>             }
>>>             return false;
>>>         }
>>      asList(a, b, c).contains(en)
>> Collection literals would help marginally.
> It's true, but I think that this must be on java.lang.Enum.
>> Even if you were going for mutable statics (and I still strongly suggest
>> you don't) it doesn't seem a difficult problem, so long as you don't
>> require these methods within the enum itself.
> Tom I don't understand what say (Please be patient, english is not my 
> native language)
>>  Just introduce a class
>> that contains the mapping, and add an instance to each enum. You may
>> need to implement a one-method interface if you want to initialise the
>> mappings from MyEnum.values().
> But one additional class for every enum (exist more than 350 enums on my 
> application) add to many code to map code-enum (I like to remove 
> unnecesar code)
>> Tom
> Thank you, Tom

More information about the coin-dev mailing list