Combining records and enumerations

[Aaron Scott-Boddendijk]

 > But we concluded that it fell short of the "carries its weight"
threshold.

This wording seemed stronger than 'we have other priorities' (which I agree
with)...

There is a distinction between a feature whose value fails to balance the
complexity it
adds to the platform and a feature which we don't have time for.

I was challenging the first interpretation, as the feature would be useful
in enough cases
and reduce such a substantial proportion of the ceremony otherwise involved
that it
seems valuable given so many moving parts already exist.

I agree the pattern-matching work is more immediately valuable. I don't
agree with
discarding good ideas based on immediately available engineering effort...
Sometimes
lower priority ideas combine in ways that warrant reevaluation of their
priority (at least
this has been my experience).

It would be interesting to keep an ideas bucket around, maybe even with
captured topical
threads. Such a beast would be useful for reexamination (and deflecting it
when it covers
the same ground) but also as a trove of 'how might this interact with...'

> Naming things is hard.

I have to give you that one - especially with "destructurer" :)

--
Aaron

On Fri, Oct 15, 2021 at 1:40 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> On 10/14/2021 7:43 AM, Aaron Scott-Boddendijk wrote:
> > 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.
>
> As I said, it's not a *bad* feature, it just has a worse return on
> investment than other features we could be working on.  We could
> prioritize this, but we'd have to deprioritize something else. Should we
> delay deconstruction patterns for six more months to make room for
> this?  Deconstruction patterns seem way more powerful.
>
> > 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).
>
> Naming things is hard.
>
> We considered using "destructuring" for all the reasons you suggest, but
> it is not without its problems either.  First, destructuring is a more
> general term than the concept being described here; what we are callling
> a "deconstruction pattern" is merely one form of destructuring, and
> there will be others.  And the name "destructurer" is impossible to
> spell or pronounce correctly.  More importantly, in the object model,
> this is the dual of construction, and to the degree users can see it
> that way, they will understand the concept more immediately.  Later
> features will be built on matching pairs of constructor and
> deconstructor (or deconstruction pattern).  The similarity in naming is
> important.
>
> The main problem with "deconstructor" is the potential confusion with
> "destructor" in C++.
>
> Naming things is hard.
>
>