Please rethink extended enums inclusion

[Jose Antonio Illescas Del Olmo]

Tom, also exists "utility" method:

    in(T...): boolean

Please, see this example as a simple scenario to use abstract enums, on 
my project exist more examples...

   On the past, prior to jdk 1.5, we can implement "enums" with 
hierarchies... and declare methods on abstract classes ("enums")

Did you known? www.extended-enums.org



On 07/10/2011 16:44, Tom Hawtin wrote:
> On 07/10/2011 15:32, Jose Antonio Illescas Del Olmo wrote:
>
>> Tom, this is an error on my example (setCode must be private), sorry
>
> Ah, so it'd be clearer if it didn't exist at all and code was made final.
>
> All that needs to be added per enum is a bit of boilerplate.
>
> Instead of (common pieces omitted):
>
>
> public enum Type extends CodeNamedEnum<Type> {
>
> private Type(String code) {
>     super(code);
> }
>
>
> We have:
>
>
> public enum Type implements CodeNamed  {
>
> private final String code;
>
> private Type(String code) {
>     this.code = code;
> }
>
> @Override public String code() {
>      return code;
> }
>
> public static final CodeMap<Type> CODES = new CodeMap<>(values());
>
>
> (Self-registration in the constructor is an alternative to the 
> interface, but makes CODES mutable (although there is a clean way of 
> protecting it from outsiders) and is somewhat tricky with respect to 
> initialisation order.)
>
>
> I don't think that is *so bad* that it requires a language change 
> (which I'm guessing wouldn't be a simple as it appears!).
>
> Tom
>