Combining records and enumerations

[Aaron Scott-Boddendijk]

In two of my projects (unfortunately closed-source), both with over 100
enums, nearly half look like they would convert to this pattern (our enums
often have additional attributes, a strength of Java enums).

There's a significant percentage of the enum-type body dedicated to
ceremony that this would eliminate.

For a small proportion in each it also looks likely that destructuring
_would_ be useful as the enums implement interfaces (another nice Java enum
strength) and apply logic that should map well to pattern-matching.

A single-line method syntax for delegation to the interface methods would
further build on this.

FYI, I really dislike the deconstruction term, as in general conversation
'construction' tends to imply allocation as well as constructor invocation.
Destructuring seems a more precise term and one that several languages
already use - and it then also covers destructuring patterns for types for
which there was no equivalent 'constructor' (eg array/slice destructuring
patterns).

--
Aaron


On Thu, Oct 14, 2021 at 9:22 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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.
>
> 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.
>
>
>
> 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.
> >
>
>