enhanced enums - back from the dead?

[Remi Forax]

There is also a non empty intersection between a sum type and an enum type, obviously you can swith on both of them, but more generally an abstract enum (an enum that uses subclassing) is a specialized version of a sum type. And if we generalize sum types to allow constants, we are bridging the gap further between sum types and enums. 

By example, a functional list can be declared like this 
sum List<T> { 
record Node<T>(T value, Node<T> next), 
EMPTY<T> 
} 
... 
var list = new Node<>(3, new Node<>(2, EMPTY)); 

Rémi 

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 12 Décembre 2018 18:01:06
> Objet: Re: enhanced enums - back from the dead?

> Yes, you could spin this feature as “its sort of for experts”, note the
> incremental complexity, and then raise the “why bother” flag. That’s a valid
> question.

> But, I prefer to look at this feature in a different way. This is not, IMO, just
> “let’s make enums do more.” This is about _simplifying_ the language model by
> removing gratuitous interactions between features. Enums are a constrained form
> of classes, one whose instances are singletons managed by the runtime. Because
> the user gives up instance control, we’re able to reward the user with things
> like equals/hashCode/toString, serialization, etc. That’s a good trade. Enums
> can still use most of the things that classes have — fields, methods,
> constructors, interfaces. But there’s no reason they can’t be generic, and
> allowing that would reduce the inessential differences between enums and
> classes.

> The other asymmetry is newer; since we inferred sharp types for anonymous
> classes when we did LVTI, inferring a weaker type for enum constants is now an
> asymmetry (one we were aware of when we did LVTI, but the plan all along was to
> align these.)

> I know that I personally have run into both of these limitations at least once
> in every large project I’ve ever done. You start out with an enum, for good
> reasons, then you hit the limits, and then have to refactor to classes,
> manually inflating the instance control boilerplate. Its frustrating, in part,
> because its unnecessary. There’s nothing inconsistent about generic enums; it’s
> just an accidental “pick one” constraint that you discover when you find
> yourself wanting both.

> So, I prefer to look at this feature as “regularization” or “removing gratuitous
> interactions”, rather than “making enums more complicated.” (It’s in the same
> category as some other things we’re considering, such as allowing local
> methods, or refining the awful rules about static members in nested classes.)
> All of these are accidental sharp edges, that create unnecessary cognitive load
> for users to keep track of which features can be used in conjunction with which
> others.

>> On Dec 12, 2018, at 11:40 AM, Kevin Bourrillion < [ mailto:kevinb at google.com |
>> kevinb at google.com ] > wrote:

>> On Tue, Dec 11, 2018 at 12:25 PM Brian Goetz < [ mailto:brian.goetz at oracle.com |
>> brian.goetz at oracle.com ] > wrote:

>>> This uber-conservative approach seems a pretty reasonable approach to
>>> me; after all, enums are a language feature, and Enum<T> is a
>>> constrained class (can't implement it directly), so it is not
>>> unreasonable to define its typing wrt its supertypes specially.

>>> So, let's get back to Maurizio's original question, which is: At one
>>> point, we thought this feature was pretty cool, and invested some work
>>> in it. Then we ran into a roadblock, and wrote it off. Now, we've got
>>> a reasonable way to clear the roadblock. Which brings us back to:

>>> - Do we still like the features described in JEP 301?

>> 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)?

>> If not, and we can stipulate that the need is rare, this means it will be a very
>> special tool for very special people; a dark corner in the language feature set
>> that most Java developers will never have need to know -- until they suddenly
>> encounter code that uses it, upon which they need to invest an amount of effort
>> understanding what is going on, even though they may have 14 years of believing
>> they understood enums under their belts already. And if the need is this rare,
>> this effort they put in might never be fully paid back.

>> On the flip side, for a developer who does have this use case, and could benefit
>> from the feature, what are the chances that developer will even know about it?
>> It may be so special-purpose that we have no real reason to assume they'll know
>> what to do.

>> On top of this, it seems the feature apparently has a blast radius onto aspects
>> of enum design that have previously been stable.

>> Can a 0.1% use case ever really be worth this?

>> --
>> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
>> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181212/8ef36d35/attachment-0001.html>