On 08/12/2018 12:45, fo...@univ-mlv.fr wrote:
----- Mail original -----
De: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>
Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
Envoyé: Samedi 8 Décembre 2018 00:57:58
Objet: Re: enhanced enums - back from the dead?
[...]
It's not that i don't like the feature, it's that for me it's a feature you can
not even put in the box of the features that we could do. We start with "hey we
could do this !" but there are some typing issues. Now, what your are saying is
that we can use raw types to not have the typing issues, but as i said above,
you are trading an error to a bunch of warnings, doesn't seems to be a good
deal*.
I agree that having too many warnings is bad - in my experiment,
although I touched a lot of code, including stream chains, I did not
find them; Comparator.comparing is probably one of the worst beast (and
doesn't work well with target typing even beside generic enums). Not
sure if that shifts the balance one way or another, but point taken.
On this topic, since I was there, I tried to tweak the prototype so that
Enum.values() and Enum.valueOf() return wildcards Foo<?>, but supertype
is Enum<Foo> and this seem to work surprisingly well, both in the tests
I had and in the new one you suggest. Maybe that would minimize the raw
type usage, pushing it quite behind the curtains, and strictly as a
migration aid for APIs such as EnumSet/Map ?
Using Enum<Foo<?>> should also work ? no ?
No, we have tried that path and that doesn't work - ultimately you get
an issue because EnumSet.of is accepting a Class<T>, and, in case of a
class literal, you get back a Class<Foo> (Foo raw). So if supertype says
Class<Foo<?>> you get two incompatible constraints on T, namely Foo and
Foo<?>.
Maurizio
Maurizio
Rémi
