Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123410
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------sKnfNo4LG6aFTG9v5OyabMq3"
Message-ID: <87a6de60-cf6e-471b-ab6d-dee005da622e@rwec.co.uk>
Date: Thu, 23 May 2024 11:38:21 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Discussion] Implicitly backed enums
To: internals@lists.php.net
References: <fcb90d5b-ac31-49b5-bf72-ed8654c34053@scriptfusion.com>
 <da922505-5cb3-44ac-916c-fbb7f864707b@app.fastmail.com>
 <99c30f5d-e2f3-4027-a8fc-b3b9c71fb6d1@scriptfusion.com>
 <1286eed1-c35e-40ec-a6f0-84926c99c911@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <1286eed1-c35e-40ec-a6f0-84926c99c911@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------sKnfNo4LG6aFTG9v5OyabMq3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 22/05/2024 00:31, Larry Garfield wrote:
> I could see an argument for auto-populating the backing value off the enum name if it's not specified, something like this:
>
> enum Options: string {
>    case First; // This implicitly gets "First"
>    case Second = '2nd';
> }


This reminds me of the short-hand key-value syntax that JavaScript 
allows, and people have occasionally requested equivalents for in PHP, 
where { foo } is equivalent to { 'foo': foo }

The downside I see to all such short-hands is that they make it much 
harder to refactor safely, because the identifier and the string value 
are tied together.

For instance, maybe you want to rename Options::First to Options::Legacy 
and Options::Second to Options::Modern so you edit the enum, and find 
all references in code:

enum Options: string {
   case Legacy;
   case Modern = '2nd';
}

But now everywhere you've serialized the old value of "First" is going 
to break, because the first case now has the implicit backing value of 
"Legacy" instead!

To avoid this, you have to go ahead and specify all the backing values:

enum Options: string {
   case Legacy = 'First';
   case Modern = '2nd';
}

Having to specify both the name and value in the first place makes that 
decision much more obvious, for what seems to me to be very little 
up-front cost.

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------sKnfNo4LG6aFTG9v5OyabMq3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 22/05/2024 00:31, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1286eed1-c35e-40ec-a6f0-84926c99c911@app.fastmail.com">
      <pre>I could see an argument for auto-populating the backing value off the enum name if it's not specified, something like this:

enum Options: string {
  case First; // This implicitly gets "First"
  case Second = '2nd';
}</pre>
    </blockquote>
    <p><br>
    </p>
    <p>This reminds me of the short-hand key-value syntax that
      JavaScript allows, and people have occasionally requested
      equivalents for in PHP, where { foo } is equivalent to { 'foo':
      foo }</p>
    <p>The downside I see to all such short-hands is that they make it
      much harder to refactor safely, because the identifier and the
      string value are tied together.</p>
    <p>For instance, maybe you want to rename Options::First to
      Options::Legacy and Options::Second to Options::Modern so you edit
      the enum, and find all references in code:<br>
    </p>
    <pre>enum Options: string {
  case Legacy;
  case Modern = '2nd';
}</pre>
    <p></p>
    <p>But now everywhere you've serialized the old value of "First" is
      going to break, because the first case now has the implicit
      backing value of "Legacy" instead!<br>
    </p>
    <p>To avoid this, you have to go ahead and specify all the backing
      values:<br>
    </p>
    <pre>enum Options: string {
  case Legacy = 'First';
  case Modern = '2nd';
}</pre>
    <p></p>
    <p>Having to specify both the name and value in the first place
      makes that decision much more obvious, for what seems to me to be
      very little up-front cost.</p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------sKnfNo4LG6aFTG9v5OyabMq3--