Dlaczego literały wyliczenia Java nie powinny mieć ogólnych parametrów typu?

Wyliczenia Java są świetne. Więc są generyczne. Oczywiście wszyscy znamy ograniczenia tego ostatniego z powodu wymazywania typów. Ale jest jedna rzecz, której nie rozumiem, dlaczego nie mogę utworzyć takiego wyliczenia:

public enum MyEnum<T> {
    LITERAL1<String>,
    LITERAL2<Integer>,
    LITERAL3<Object>;
}

Ten parametr typu ogólnego <T>może z kolei być przydatny w różnych miejscach. Wyobraź sobie ogólny parametr typu dla metody:

public <T> T getValue(MyEnum<T> param);

Lub nawet w samej klasie enum:

public T convert(Object o);

Bardziej konkretny przykład nr 1

Ponieważ powyższy przykład może wydawać się zbyt abstrakcyjny dla niektórych, oto bardziej prawdziwy przykład, dlaczego chcę to zrobić. W tym przykładzie chcę użyć

• Wyliczenia, ponieważ wtedy mogę wyliczyć skończony zestaw kluczy właściwości
• Generics, ponieważ wtedy mogę mieć bezpieczeństwo typu na poziomie metody do przechowywania właściwości

public interface MyProperties {
     public <T> void put(MyEnum<T> key, T value);
     public <T> T get(MyEnum<T> key);
}

Bardziej konkretny przykład nr 2

Mam wyliczenie typów danych:

public interface DataType<T> {}

public enum SQLDataType<T> implements DataType<T> {
    TINYINT<Byte>,
    SMALLINT<Short>,
    INT<Integer>,
    BIGINT<Long>,
    CLOB<String>,
    VARCHAR<String>,
    ...
}

Każdy literał wyliczenia miałby oczywiście dodatkowe właściwości oparte na typie ogólnym <T> , będąc jednocześnie wyliczeniem (niezmiennym, pojedynczym, wyliczalnym itp.)

Pytanie:

Czy nikt o tym nie pomyślał? Czy to jest ograniczenie związane z kompilatorem? Biorąc pod uwagę fakt, że słowo kluczowe „ enum ” jest zaimplementowane jako cukier składniowy, reprezentujący wygenerowany kod w JVM, nie rozumiem tego ograniczenia.

Kto może mi to wyjaśnić? Zanim odpowiesz, zastanów się:

• Wiem, że typy ogólne są usuwane :-)
• Wiem, że istnieją obejścia przy użyciu obiektów Class. To obejścia.
• Typy ogólne skutkują rzutami typów generowanych przez kompilator wszędzie tam, gdzie ma to zastosowanie (np. Podczas wywoływania metody convert ()
• Typ ogólny <T> znajdowałby się w wyliczeniu. Stąd jest on związany przez każdy z literałów wyliczenia. Dlatego kompilator wiedziałby, jaki typ zastosować podczas pisania czegoś takiegoString string = LITERAL1.convert(myObject); Integer integer = LITERAL2.convert(myObject);
• To samo dotyczy parametru typu ogólnego w T getvalue()metodzie. Kompilator może zastosować rzutowanie typu podczas wywoływaniaString string = someClass.getValue(LITERAL1)

Jest to obecnie omawiane jako ulepszone wyliczenia JEP-301 . Przykład podany w JEP to dokładnie to, czego szukałem:

enum Argument<X> { // declares generic enum
   STRING<String>(String.class), 
   INTEGER<Integer>(Integer.class), ... ;

   Class<X> clazz;

   Argument(Class<X> clazz) { this.clazz = clazz; }

   Class<X> getClazz() { return clazz; }
}

Class<String> cs = Argument.STRING.getClazz(); //uses sharper typing of enum constant

Niestety JEP wciąż boryka się z istotnymi problemami: http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-May/000041.html

Odpowiedź jest w pytaniu:

z powodu usunięcia typu

Żadna z tych dwóch metod nie jest możliwa, ponieważ typ argumentu jest usuwany.

public <T> T getValue(MyEnum<T> param);
public T convert(Object);

Aby zrealizować te metody, możesz jednak skonstruować wyliczenie jako:

public enum MyEnum {
    LITERAL1(String.class),
    LITERAL2(Integer.class),
    LITERAL3(Object.class);

    private Class<?> clazz;

    private MyEnum(Class<?> clazz) {
      this.clazz = clazz;
    }

    ...

}

Ponieważ nie możesz. Poważnie. Można to dodać do specyfikacji języka. Nie było. Dodałoby to trochę złożoności. Ta korzyść kosztowa oznacza, że ​​nie jest to wysoki priorytet.

Aktualizacja: obecnie dodawane do języka pod JEP 301: Rozszerzone wyliczenia .

Istnieją inne metody w ENUM, które nie zadziałają. Co by MyEnum.values()zwróciło?

O co chodzi MyEnum.valueOf(String name)?

Dla valueOf, jeśli uważasz, że kompilator może utworzyć metodę ogólną, taką jak

public static MyEnum valueOf (nazwa ciągu);

żeby to nazwać jak MyEnum<String> myStringEnum = MyEnum.value("some string property") , to też nie zadziała. Na przykład co jeśli zadzwonisz MyEnum<Int> myIntEnum = MyEnum.<Int>value("some string property")? Nie jest możliwe zaimplementowanie tej metody, aby działała poprawnie, na przykład aby zgłosić wyjątek lub zwrócić wartość null, gdy wywołujesz ją tak, jak z MyEnum.<Int>value("some double property")powodu wymazywania typu.

Szczerze mówiąc, wydaje się to bardziej rozwiązaniem w poszukiwaniu problemu niż czegokolwiek.

Całym celem wyliczenia Java jest modelowanie wyliczenia wystąpień typów, które mają podobne właściwości w sposób zapewniający spójność i bogactwo wykraczające poza porównywalne reprezentacje typu String lub Integer.

Weź przykład enum z podręcznika. To nie jest zbyt przydatne ani spójne:

public enum Planet<T>{
    Earth<Planet>,
    Venus<String>,
    Mars<Long>
    ...etc.
}

Dlaczego miałbym chcieć, aby moje różne planety miały różne konwersje typów ogólnych? Jaki problem rozwiązuje? Czy uzasadnia to komplikowanie semantyki języka? Jeśli potrzebuję tego zachowania, czy wyliczenie jest najlepszym narzędziem do osiągnięcia tego?

Poza tym, jak zarządzasz złożonymi konwersjami?

na przykład

public enum BadIdea<T>{
   INSTANCE1<Long>,
   INSTANCE2<MyComplexClass>;
}

Wystarczy String Integerpodać nazwę lub numer porządkowy. Ale leki generyczne pozwoliłyby na dostarczenie dowolnego typu. Jak poradzisz sobie z konwersją do MyComplexClass? Teraz zbierasz dwie konstrukcje, zmuszając kompilator, aby wiedział, że istnieje ograniczony podzbiór typów, które można dostarczyć do ogólnych wyliczeń i wprowadzając dodatkowe zamieszanie w koncepcji (Generics), która wydaje się wymykać się wielu programistom.

Becasue „enum” to skrót od wyliczenia. To tylko zbiór nazwanych stałych, które zastępują liczby porządkowe, aby kod był bardziej czytelny.

Nie rozumiem, jakie może być zamierzone znaczenie stałej sparametryzowanej na typ.

Myślę, ponieważ w zasadzie wyliczenia nie mogą być instancjami

Gdzie ustawiłbyś klasę T, gdyby JVM pozwolił ci to zrobić?

Wyliczenie to dane, które mają być zawsze takie same lub przynajmniej takie, że nie zmieniają się dynamicznie.

nowy MyEnum <> ()?

Wciąż przydatne może być poniższe podejście

public enum MyEnum{

    LITERAL1("s"),
    LITERAL2("a"),
    LITERAL3(2);

    private Object o;

    private MyEnum(Object o) {
        this.o = o;
    }

    public Object getO() {
        return o;
    }

    public void setO(Object o) {
        this.o = o;
    }   
}