JEP 301: Enhanced Enums

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: forax at univ-mlv.fr
> Cc: platform-jep-discuss at openjdk.java.net
> Envoyé: Jeudi 8 Décembre 2016 01:10:03
> Objet: Re: JEP 301: Enhanced Enums

> On 07/12/16 22:28, forax at univ-mlv.fr wrote:
>>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>, platform-jep-discuss at openjdk.java.net
>>> Envoyé: Mercredi 7 Décembre 2016 10:48:44
>>> Objet: Re: JEP 301: Enhanced Enums
>>> Thanks for the feedback. I personally run into the lack of sharp typing
>>> several times and seen other people stumbling on it too.
>>>
>>> Do you have some example in mind that will break - other than the ones
>>> listed in the JEP? In my mental model, the kind of surprises this
>>> introduces are very similar to anonymous inner class types - that is:
>>>
>>> new Object() { void m() { } }.m();
>>>
>>> this is legal code because the receiver expression doesn't have type
>>> Object - but has a sharper type (which can 'see' the additional member).
>>> This proposal is about doing the same with enums - which accidentally
>>> will sit well with adding generics (because in that case, the constants
>>> will have a richer generic type than their parent).
>>
>> Abstract enum where introduces as a kind of strawman lambdas (see [1]),
>> and as Stephen said there were intentionally restricted to not be more than
>> that.
> The video you quote talks about enums inheritance - this JEP in no way
> affects the way in which enum can (or rather can't) subclass each other
> (and in fact this is even called out in the JEP). For illustrating the
> problem this JEP addresses, you don't need fancy hierarchies - all it
> takes is something simple like this:
> 
> enum Foo {
>    A() { void a() { ... } },
>    B,
>    C() { void c() { ... } };
> 
>    void m() { ... }
> }
> 
> Here we have three constants - they all have a method m() - one constant
> (A) has a method a() and another constant (C) has a method c().
> 
> This is not some theoretical example - think of an enum modelling e.g.
> JVM primitive types - it's not that unreasonable to have operation on
> certain types but not on others - for instance you can do a conditional
> jump on an int ( 'if_icmp') - but you cannot do the same on floats
> (there's no 'if_fcmp'). Or maybe, some operation returns a result of one
> type in some case, but something of a different result in other cases -
> for instance, loading an int (iload) gives you an int - loading a float
> (fload) gives you a float.
> 
> Now, how do we implement these things if we want to use today's enums?
> One common (and ugly!) idiom seems to be this:
> 
> enum Foo {
>    A,
>    B,
>    C;
> 
>    void m() { ... }
> 
>    void a() {
>         switch (this) {
>             case A: //do something
>             default: throw
>        }
>    }
> 
>    void c() {
>         switch (this) {
>             case C: //do something
>             default: throw
>        }
>    }
> }
> 
> This has, IMO, several issues:
> 
> * encapsulation is broken - methods are not declared where they really
> belong
> * no static safety - the compiler doesn't blink if you say Foo.B.c();
> * readability - every method needs to be turned inside out into a switch
> 
> The goal of this JEP is to make stuff like this easier to write - and we
> want to be able to get there so that the extra typing information is
> there _if you need it_. If you don't care about the sharp types, fine -
> they won't harm you either (and for the most part you can pretend they
> don't even exist).

Why do you want to encode a hierarchy as an enum ?
It's OO 101, you create 3 classes, A, B, C, an interface Foo and an abstract class AbstractFoo that contains the code of m() (or maybe use a default method in Foo if like in your example Foo has no field).
And your done.

Enum were not created to be a short syntax for encoding a hierarchy, and to avoid that, the EG that introduces the Enum feature make it clear by forcing all values of an enum to be typed with the enum type.
And as Josh Blosch said in the video, they also wanted to allow to encode what Josh calls 'named function' by allowing abstract enums. Name functions are not useful anymore, because now we have full real lambdas. So there is no reason to use abstract enums anymore, no reason to have enum values with different subclasses even if i agree with you that the syntax for that is short and cool.

> 
> Maurizio

Rémi

>>
>>> Maurizio
>> Rémi
>>
>> [1] https://youtu.be/pi_I7oD_uGI?t=2041
>>
>>>
>>> On 07/12/16 09:03, Remi Forax wrote:
>>>> Now, If this proposal is accepted, at least, instead of changing the spec to
>>>> introduce sharp types for all kind of enums, adding sharp type only for
>>>> generics enums,
> >>> it will break no code because generics enum currently do not compile.