Sorrt for the very late reply - yesterday I was writing this, but got
hijacked by Xmas party :-)
On 12/12/2018 16:40, Kevin Bourrillion wrote:
What proportion of enum use cases benefit from this? Offhand, I would
have to guess that it is less than 0.1% (and if it turned out to be
/far/ less it wouldn't /shock/ me). Does anyone believe it's /likely
enough/ to be >0.1% that it's worth my effort to try to research that
question in our codebase (which would take a bit of work)?
Yes, this is THE question, but it is also a very tough one. I don't
think this is one of those cases where one can write some kind of
automated 'finder' which will tell you how often a given feature can be
used in an existing code base; we were able to do that for 'var', for
diamond, for lambdas. This is something very different, because looking
for it essentially means looking for 'near misses' where maybe authors
wished they had generics back when they wrote the enum, but they had to
settle for some compromise.
Example:
http://hg.openjdk.java.net/jdk/jdk/file/24525070d934/src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java
And this falls into the 'easy' category - after all, this is still an
enum, so it can be searched for. But how do we find the _classes_ that
*could* be enums, but aren't simply because they are using generics (the
same applies for other features not readily available in enums, e.g.
local enums)? These cases are much more difficult (if not impossible) to
spot!
Other instance that I found in the JDK codebase is that of enums which
accept some 'stringified' key - e.g. something like this:
hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/sun/security/rsa/RSAUtil.java
I'm not an expert of this specific piece of code, but as in the Option
enum experimement I did with javac, I believe that eager stringification
is something that in principle could be cured by having more
expressiveness in the enum declaration (e.g. have the key be a class,
not a string!)
So I think this feature is, as Brian says, about removing unnecessary
discrepancies between classes and enums - discrepancies that, in the
past, might have tilted code one way or another; it might be hard now to
evaluate precisely how much code has been tilted - within the JDK team,
it looked as though many of us had this 'moment' where we wished that
something like this was indeed possible.
Maurizio
