2 questions about enums and the closed/withdrawn JEP 301

[Archie Cobbs]

On Wed, Mar 29, 2023 at 1:58 AM Red IO <redio.development at gmail.com> wrote:

> The possibility to add This regardless of the Enum class should still be
> considered though.
>

Can I say "me too"?? :) I've always wanted to be able to declare an
instance method whose return type is the same type as the instance. In
fluent API's, it would eliminate a bunch of override methods that are only
there to narrow the return type.

On the enum question...

When I was programming Java before there were enums, I would homebrew my
own enums.

When enums were invented, I thought "Great! The compiler will do all that
stuff for me". I could clearly see that it was just a matter of the
compiler automatically doing a transformation I was already doing manually.

Today when I want a generic enum type, I go back to homebrewing my own
enums just like before, with generic parameter(s) as needed.

So from a practical perspective most developers probably don't understand
why this shouldn't be "easy". If a developer can do it manually, the
compiler should be able to do it automatically.

Also, it's kind of perplexing that the show-stopping barrier here is not
with the Enum type itself, but with the EnumSet/EnumMap utility classes.

Regarding that problem, would it work to just add "workaround" methods like
this?

        public static <T extends Enum<T>> EnumSet<T> noneOfGeneric(Class<?
extends T> klass)

Even though klass has type Class<? extends T>, at compile time, you're not
going to be able to specify any Class constant other than the top enum
class, so no problem there, and at runtime, this method could do
introspection to find the top enum class (if necessary; unlikely) and then
use that.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230329/1daa386a/attachment.htm>