Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112754
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <eb92cb31-9c2c-31a6-e352-0f0f84be1a54@gmail.com>
Date: Mon, 4 Jan 2021 17:04:16 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <DA8957D9-279D-4979-9CE5-D80B25C41489@newclarity.net>
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <8aa05350-05fc-df9d-e5d6-fa0f4feb57ba@alec.pl>
 <fdbc8779-de22-46a1-ab6e-e3cfb34565b4@www.fastmail.com>
 <c3dfee4f-6f54-9b4a-a599-fb016ed6a110@alec.pl>
 <4eec7448-f7ab-9955-8c2d-68cd4f822535@gmail.com>
 <7d8ce2a2-8d85-4312-af22-da643faa3a7f@www.fastmail.com>
 <1BC8BF20-B961-4360-855B-5BB95338BB8A@newclarity.net>
 <d07b38e1-78f9-822e-f3be-a4ed42b6702b@fischer.name>
 <eb92cb31-9c2c-31a6-e352-0f0f84be1a54@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: mike@newclarity.net (Mike Schinkel)

> On Jan 4, 2021, at 9:05 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 04/01/2021 11:15, Markus Fischer wrote:
>> On 03.01.21 12:01, Mike Schinkel wrote:
>>> So in my perfect world this:
>>>=20
>>> enum BookingStatus {
>>>       case PENDING;
>>>       case CONFIRMED;
>>>       case CANCELLED;
>>> }
>>>=20
>>> Would be equivalent to:
>>>=20
>>> enum BookingStatus {
>>>       case PENDING =3D "PENDING";
>>>       case CONFIRMED =3D "CONFIRMED";
>>>       case CANCELLED =3D "CANCELLED";
>>> }
>>=20
>> I'm with Mikes' suggesting here, see also my previous messages [1] =
[2].
>>=20
>> I don't know how to back this up with numbers, but the way I see it =
the majority of use cases will have a benefit of being able to directly =
use the literal values derived from the lexical ones and the ability to =
have custom values is feature next to it.
>=20
>=20
> I would personally be OK with this if it was allowed but opt-in, e.g. =
adding the ": string" would default the values in that way, or even =
something magic like ": auto".
>=20
> I'm still not a fan of having values *always* defined, because I want =
to be able to pick case labels without worrying about whether they make =
sense as values.

>=20
> For instance, there's a similar maintenance issue to named parameters: =
having a default value means if I write "case PENDING;" in v1.0, I can't =
change that to "case PENDING=3D'P';" or "case PENDING=3D1;" in v1.1, in =
case somebody is relying on the value being 'PENDING', which was never =
intended.

You make a good point about being able to define without defaults, and =
for being opt-in instead.

A use-case I am thinking about is a long list of application-specific =
error codes where you don't want to have to come up two values for each =
error code and/or worry about keeping them the same.


I don't quit get how you are thinking of with ": string"; can you give =
an example?

Conversely, (something like) this might be a viable way to opt-in =
default values:

enum defaults BookingStatus {
      case PENDING;
      case CONFIRMED;
      case CANCELLED;
}

-Mike=