Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112724
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: <7d8ce2a2-8d85-4312-af22-da643faa3a7f@www.fastmail.com>
Date: Sun, 3 Jan 2021 06:01:54 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1BC8BF20-B961-4360-855B-5BB95338BB8A@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>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: mike@newclarity.net (Mike Schinkel)



> On Dec 31, 2020, at 12:15 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Thu, Dec 31, 2020, at 6:53 AM, Rowan Tommins wrote:
>> On 30/12/2020 21:24, Aleksander Machniak wrote:
>>> My argument is that, from an end-user perspective, I don't really =
see
>>> why Unit and Scalar enums have to have different "API" at this =
point.
>>> I'm talking about ":string"/":int" in the enum definiton as well as
>>> ->value and ->from().
>>=20
>>=20
>> My personal opinion is that for many enums, explicitly not having a=20=

>> scalar representation is a good thing.
>>=20
>> This is basically similar to my opinion of __toString() etc: if you =
have=20
>> *multiple* ways to convert something to/from a scalar, blessing one =
of=20
>> them as "default" is arbitrary and confusing.
>>=20
>> For example:
>>=20
>> enum BookingStatus {
>>      case PENDING;
>>      case CONFIRMED;
>>      case CANCELLED;
>>=20
>>      public function getId() {
>>            return match($this) {
>>                 self::PENDING =3D> 1,
>>                 self::CONFIRMED =3D> 2,
>>                 self::CANCELLED =3D> 3,
>>            };
>>      }
>>      public function getCode() {
>>            return match($this) {
>>                 self::PENDING =3D> 'PEN',
>>                 self::CONFIRMED =3D> 'CON',
>>                 self::CANCELLED =3D> 'CAN',
>>            };
>>      }
>>      public function getEnglishDescription() {
>>            return match($this) {
>>                 self::PENDING =3D> 'Pending Payment',
>>                 self::CONFIRMED =3D> 'Confirmed',
>>                 self::CANCELLED =3D> 'Cancelled',
>>            };
>>      }
>> }
>=20
> That is similar to our reasoning.  It creates a foot-gun situation =
where someone could get in the habit of assuming that an enum always has =
a *reasonable* and *logical* and thus *reliable* string equivalent, when =
not all enums will have string equivalents that it's reasonable and =
logical to use.  So, one less foot gun.

However, avoiding one foot-gun does not always mean that you avoid all =
foot-guns.

For example, when you need to create a large number of string enums =
where the name and the symbol are the same, it would be very easy to =
have a typo in one but not the other, especially as a result of copy and =
paste editing.

So in my perfect world this:

enum BookingStatus {
     case PENDING;
     case CONFIRMED;
     case CANCELLED;
}

Would be equivalent to:

enum BookingStatus {
     case PENDING =3D "PENDING";
     case CONFIRMED =3D "CONFIRMED";
     case CANCELLED =3D "CANCELLED";
}

#fwiw

>=20
> Also, one of the extensions planned, as noted, is ADTs/tagged unions.  =
Those could not have a primitive equivalent, since they're not =
singletons.  Keeping UnitEnum and ScalarEnum separate allows us to later =
add TaggedEnum (or similar) that also extends UnitEnum, but not =
ScalarEnum.
>=20
> --Larry Garfield
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20