enhanced enums - back from the dead?

[Kevin Bourrillion]

On Tue, Dec 11, 2018 at 12:25 PM Brian Goetz <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. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181212/c05f7703/attachment.html>