Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123409
Precedence: bulk
MIME-Version: 1.0
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> <3cac0454-ceb2-449a-8b9a-1fac3f866a9c@scriptfusion.com>
 <9c763cee-6524-4423-b95e-6bfff4763d2e@app.fastmail.com>
In-Reply-To: <9c763cee-6524-4423-b95e-6bfff4763d2e@app.fastmail.com>
Date: Thu, 23 May 2024 08:35:09 +0200
Message-ID: <CAPzBOBNePs4LEx6+EztNWB76pHzKsN6818_0n1QmWfbOO-NJFw@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discussion] Implicitly backed enums
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Wed, May 22, 2024 at 4:13=E2=80=AFAM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Tue, May 21, 2024, at 6:47 PM, Bilge wrote:
> > 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 =3D '2nd';
> >> }
> > This seems like a reasonable compromise. In this case, all I need to do
> > is change my enum to a backed enum (suffix `: string`) and I get the
> > benefits of implicit values. I still like the idea of the same being
> > possible for non-backed enums, though I imagine that is a product of my
> > na=C3=AFvet=C3=A9, as I do not tend to think of things in the framing o=
f
> > (de)serialization.
>
> Making it really hard and unnatural for people to use PHP enums as "cheap=
 named strings/ints" is something we want to keep, because the whole value =
of enums is that they are their own separate type.  A Direction is not a st=
ring, it's not an int, it's not an array, it's not a Product, it's a Direct=
ion.  That's the end of it.  Databases and HTML don't know from Direction o=
r Product, though, so it has to get serialized down to something for those.=
  For arbitrary objects, you basically have to write your own mechanism.  (=
I did.)  For enums, one comes built-in to make it more standardized: backed=
 enums.

For what it's worth, the biggest downside to this decision is in
upgrading old/legacy projects to use enums. Most of the time, you want
to convert a const to an enum, and that also usually means it will be
a backed enum. Since there's no way to cast a backed enum to a
string/int, you have to instead add ->value (I really don't understand
the difference; casting would have been much more elegant); this
almost always results in lots of hidden runtime errors. At the last
couple of places, after seeing the damage the conversion could do,
doing this conversion was simply off-limits. Maybe by now, there is
some reliable tooling to handle this automatically... I haven't
looked. The point remains that it is a strange decision to use
`->value` but not allow `(string)` or `(int)` or allow even
implementing it yourself.

>
> >> I'm not sure if I'd support it myself at the moment
> > Noted, but I once again find myself needing to ask: why not? Were it up
> > to me, I'd say let's start right now! :)
>
> Mainly because I haven't thought it through to see what possible issues i=
t could cause.  It may be safe, or there may be currently-not-obvious issue=
s that would result.  That's the sort of thing we'd need to explore.
>
> For instance, how useful would it be, given that the casing for an enum s=
hould be CamelCase (per PER-CS), but the serialized string is most often sn=
ake_case, and otherwise lowerCamel?  We definitely cannot bake case folding=
 magic into the behavior.  So is it even useful at that point?  I don't kno=
w.  Maybe.  That's what needs to be explored.

I don't see how casing of the backed value is relevant. If you want it
to be something different, then specify it in the class body. 9/10 of
the time, you just need to serialize the enum somewhere and the casing
doesn't matter. If it does matter, then specify the values manually.

>
> It's not something I'm planning to work on myself at this point, though i=
f someone else wanted to dig into it I'm happy to help brainstorm with them=
.
>
> --Larry Garfield