Combining records and enumerations

[Remi Forax]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Simon Ritter" <sritter at azul.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Sent: Mercredi 13 Octobre 2021 22:22:13
> Subject: Re: Combining records and enumerations

> Yes, we considered exactly this during the design process of records.
> 
> There's nothing _wrong_ with this, and it's consistent with what records
> does with the component list.  But we concluded that it fell short of
> the "carries its weight" threshold.  Records acquire fields, accessors,
> ctors, equals, hashCode, toString, and soon, dtors.  But enums already
> have their own equals/hashCode/toString, and deconstruction makes less
> sense, so for enums it would be only fields and ctor, and maybe
> accessors.  So the benefit is less.  Add to that that there are many
> fewer enums than there are likely to be records, the benefit is even lesser.

There is a benefit, you can not declare a non final field with this syntax.

I'm not sure it's enough to tip of the balance ...

> 
> Finally, we have deliberately held the corresponding syntactic position
> for classes uncolonized:
> 
>     class Foo(SOMETHING MIGHT GO HERE EVENTUALLY) { ... }
> 
> pending deeper thinking on what the right thing to do is.  There were
> many eager suggestions in the previous round, none of them seemed quite
> right, but its quite possible something good might emerge.  In which
> case it might make more sense for whatever goes in that position for
> enums, to be more like what classes do than like what records do.  So
> that's another reason to hold off doing anything special for enums.

Rémi

> 
> 
> 
> On 10/12/2021 4:10 PM, Simon Ritter wrote:
>> I hope this is the right list to post this to.
>>
>> I was recently using an enumeration and it struck me that enums
>> containing a constructor and member declarations could be simplified
>> by adopting some of the syntax from records.
>>
>> Here is an example of such an enumeration:
>>
>> public enum Planet {
>>   MERCURY(0.4, 0.055),
>>   VENUS(0.7, 0.815),
>>   EARTH(1.0, 1.0),
>>   MARS(0.107, 1.5);
>>
>>   private double orbitalDistance;
>>   private double earthMass;
>>
>>   Planet(double orbitalDistance, double earthMass) {
>>     this.orbitalDistance = orbitalDistance;
>>     this.earthMass = earthMass;
>>   }
>>
>>   public double orbitalDistance() {
>>     return orbitalDistance;
>>   }
>>
>>   public double earthMass() {
>>     return earthMass;
>>   }
>> }
>>
>> Most of this boiler-plate code is identical to the code eliminated by
>> a record from a simple data class.  If we took the same approach we
>> could simplify this as:
>>
>> public enum Planet(double orbitalDistance, double earthMass) {
>>   MERCURY(0.4, 0.055),
>>   VENUS(0.7, 0.815),
>>   EARTH(1.0, 1.0),
>>   MARS(0.107, 1.5);
>> }
>>
>> The grammar for enumerations would only need to be extended to include
>> an EnumHeader
>>
>> EnumDeclaration: {ClassModifier} enum TypeIdentifier EnumHeader
>> [ClassImplements] EnumBody
>>
>> with EnumHeader using the same format as RecordHeader
>>
>> EnumHeader:
>>   ( [EnumComponentList] )
>>
>> I'm assuming changes to the compiler to implement this would not be
>> overly complex (although I have not looked at the code).
>>
>> I'd be very interested to hear other people's opinion on this.
>>
>> Regards,
>>
>> Simon.