Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123394
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-480-g515a2f54a-fm-20240515.001-g515a2f54
Precedence: bulk
MIME-Version: 1.0
Message-ID: <9c763cee-6524-4423-b95e-6bfff4763d2e@app.fastmail.com>
In-Reply-To: <3cac0454-ceb2-449a-8b9a-1fac3f866a9c@scriptfusion.com>
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>
Date: Tue, 21 May 2024 19:45:55 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Discussion] Implicitly backed enums
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 21, 2024, at 6:47 PM, Bilge wrote:
> On 22/05/2024 00:31, Larry Garfield wrote:=20
>> 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: str=
ing {
>>   case First; // This implicitly gets "First"
>>   case Second =3D '2nd';
>> }=20
> This seems like a reasonable compromise. In this case, all I need to d=
o=20
> is change my enum to a backed enum (suffix `: string`) and I get the=20
> benefits of implicit values. I still like the idea of the same being=20
> possible for non-backed enums, though I imagine that is a product of m=
y=20
> na=C3=AFvet=C3=A9, as I do not tend to think of things in the framing =
of=20
> (de)serialization.

Making it really hard and unnatural for people to use PHP enums as "chea=
p named strings/ints" is something we want to keep, because the whole va=
lue of enums is that they are their own separate type.  A Direction is n=
ot a string, it's not an int, it's not an array, it's not a Product, it'=
s a Direction.  That's the end of it.  Databases and HTML don't know fro=
m Direction or Product, though, so it has to get serialized down to some=
thing for those.  For arbitrary objects, you basically have to write you=
r own mechanism.  (I did.)  For enums, one comes built-in to make it mor=
e standardized: backed enums.

>> I'm not sure if I'd support it myself at the moment=20
> Noted, but I once again find myself needing to ask: why not? Were it u=
p=20
> to me, I'd say let's start right now! :)

Mainly because I haven't thought it through to see what possible issues =
it could cause.  It may be safe, or there may be currently-not-obvious i=
ssues 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 =
should be CamelCase (per PER-CS), but the serialized string is most ofte=
n snake_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 know.  Maybe.  That's what needs to be explored.

It's not something I'm planning to work on myself at this point, though =
if someone else wanted to dig into it I'm happy to help brainstorm with =
them.

--Larry Garfield