Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112700
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <7d8ce2a2-8d85-4312-af22-da643faa3a7f@www.fastmail.com>
In-Reply-To: <4eec7448-f7ab-9955-8c2d-68cd4f822535@gmail.com>
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>
Date: Thu, 31 Dec 2020 11:15:41 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: larry@garfieldtech.com ("Larry Garfield")

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 se=
e
> > 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 ha=
ve=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 {
>  =C2=A0=C2=A0=C2=A0=C2=A0 case PENDING;
>  =C2=A0=C2=A0=C2=A0=C2=A0 case CONFIRMED;
>  =C2=A0=C2=A0=C2=A0=C2=A0 case CANCELLED;
>=20
>  =C2=A0=C2=A0=C2=A0=C2=A0 public function getId() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return m=
atch($this) {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::PENDING =3D> 1,
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::CONFIRMED =3D> 2,
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::CANCELLED =3D> 3,
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 };
>  =C2=A0=C2=A0=C2=A0=C2=A0 }
>  =C2=A0=C2=A0=C2=A0=C2=A0 public function getCode() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return m=
atch($this) {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::PENDING =3D> 'PEN',
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::CONFIRMED =3D> 'CON',
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::CANCELLED =3D> 'CAN',
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 };
>  =C2=A0=C2=A0=C2=A0=C2=A0 }
>  =C2=A0=C2=A0=C2=A0=C2=A0 public function getEnglishDescription() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return m=
atch($this) {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::PENDING =3D> 'Pending Payment',
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::CONFIRMED =3D> 'Confirmed',
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 self::CANCELLED =3D> 'Cancelled',
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 };
>  =C2=A0=C2=A0=C2=A0=C2=A0 }
> }

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 *r=
easonable* 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.

Also, one of the extensions planned, as noted, is ADTs/tagged unions.  T=
hose could not have a primitive equivalent, since they're not singletons=
.  Keeping UnitEnum and ScalarEnum separate allows us to later add Tagge=
dEnum (or similar) that also extends UnitEnum, but not ScalarEnum.

--Larry Garfield