enhanced enums - back from the dead?

[Brian Goetz]

> Thanks to your explanation I see that this case is like that one in theory. It's not quite the same thing in practice. That is, I know that a person can both read and write "switch (someLong)" with no puzzlement, but I don't think the same is true here; enumness and genericness are conceptually orthogonal but most people can only come to that understanding through a bit of confusion first, and they can't necessarily guess the right syntax to use.

So, there’s two lenses through which we can view “language complexity”.  The first is incremental complexity relative to an existing Java developer who’s already learned the old way; the second is relative to a  _new_ developer learning the new Java vs the old Java.  

Some changes add to complexity in both senses; these are when we add a whole new feature.  (Generics, lambdas, and modules are all in this category — they may still be justified on the benefits, but the costs are indisputable.)  This one, I believe, is more asymmetric; those who have invested effort in internalizing the gratuitous differences may have come to see them as normal, and now have to unlearn them, which takes more effort.  (Though even then, they may come to a point where they say “ah, that’s simpler.”)  

> Secondly, it's hard to imagine there being any unforeseen consequences of switching on a long. Here, I don't really know how to think it through yet. I would appreciate any "here's how we know that the changes we need to support this will have no user-visible consequences at all except for X, Y, and Z" type of explanation we have (apologies if I missed it).

Yep, that’s a harder one.  

In this feature, there are two changes (that we know of so far) that might cause such observable effects.  

1.  Not erasing the type parameter of Enum when computing the super type of a raw enum type.  
2.  Changing the translation of enum constants.  Right now, if you have an enum constant that has a body, it gets translated as an inner class, Foo$1.  We would probably change that to a named nested class, such as Foo$A.  

For (1), we’re all scratching our heads to imagine a negative consequence, and not coming up with one, but there is the risk of “proof by lack of imagination.”  

For (2), I think there’s more risk here; people could reflectively look up enum constants as Foo$23, and this will break, but … is this in the category of “ask a stupid question, get a stupid answer”?  (Note that for serialized instances, we’re covered, as serialization represents enum constants by name.)  

I think these are the two things to worry about.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181212/699b1e81/attachment.html>