Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127973
Precedence: bulk
MIME-Version: 1.0
References: <CADK1yXLAOgDNrXO1-t0vLKCtV2qB4L2x50JFHXxJHoUrA6GPsA@mail.gmail.com>
In-Reply-To: <CADK1yXLAOgDNrXO1-t0vLKCtV2qB4L2x50JFHXxJHoUrA6GPsA@mail.gmail.com>
Date: Wed, 9 Jul 2025 16:38:34 +0200
Message-ID: <CANS-=pdu_Epp3pbcq=WdT_E2QGGGexZLtQNxUmjn1neuHa8w5A@mail.gmail.com>
Subject: Re: [PHP-DEV] ::from() and tryFrom() on Basic Enums
To: Deleu <deleugyn@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000af37cf063980093f"
From: kjarli@gmail.com (Lynn)

--000000000000af37cf063980093f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 9, 2025 at 3:33=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:

> Hi people!
>
> Today I tried to do `ResourceType::from()` and was surprised that my IDE
> immediately screamed at me. After further investigation, I realized that
> Basic Enums (this is what the RFC called it [1]) does not have these
> commodities backed into them.
>
> I did some digging and I found 2 main discussions: Stringable by default
> [2][3] and backed-in commodities [4]. I think Benjamin, Derick and Nicola=
s
> have argued why Stringable by default may not be desirable and I only
> mention this for completeness of the conversation. I don't want to talk
> about that at all. Instead, I want to focus on the other side: construct
> from string by default (from/tryFrom()).
>
> I also read Larry's post that has been shared throughout these discussion=
s
> [5] and it seems fair and sound to use guardrails to discourage unintende=
d
> use. This gets into the territory of "let me do what I want, I know what
> I'm doing" vs "let me limit what you can do because I built it and I know
> exactly what it was intended for", which I also want to try and steer awa=
y
> from debating, each camp has its merits.
>
> Bilge said:
>
> My question, then, is why can't basic enumerations have these semantics b=
y
> default? Or, to state it more concretely, what would be the downside to
> having all "basic" enumerations actually being "backed" enumerations whos=
e
> values implicitly mirror their names for the purposes of converting to/fr=
om
> strings? Would this not make basic enumeration more useful without any
> particular downsides?
>
>
> While I'm searching for similar clarification, I want to pose the questio=
n
> differently. I feel like the answer to his question is in Larry's article
> about discouraging fancy strings. My question boils down purely to: *can
> Basic Enums implement ::from() / tryFrom() methods?*
>
> Larry said:
>
> [...] In your case, you want to "upcast" a string to an enum. That means
> you're doing some sort of deserialization, presumably. In that case, a
> backed enum is what you want. *A unit enum isn't serializable, by design.=
*
>
>
> Although this starts to thread into very pedantic territory, I think, in
> fact, a *unit enum* (assuming it means Basic enum) is in fact always
> serializable to a string: `$enum->value`. By design, the value is a strin=
g
> and it cannot have duplicate values in a single enum. It means it's
> extremely easy to define an Enum in PHP and at some point store it in a
> storage engine / database in the form of `$enum->value`. Now if I want to
> get back my Enum at a later stage I need to implement exactly the same co=
de
> that already exists in the PHP engine behind `Enum::from()`. Maybe it's n=
ot
> serializable in the sense that it doesn't implement any true serializatio=
n
> mechanism, which I'm guessing a backed-enum probably does, but I'm trying
> to come from the very practical application of creating a Basic Enum at a=
n
> HTTP context (which is the bread and butter of PHP) and then recovering
> said Enum in a background worker context without having to use PHP
> `serialize()` function and store PHP-specific dialect in a database that =
is
> used by multiple teams and programming languages.
>
> I also take the point that it is easy to argue against all this: just put
> `: string` on your Enum and duplicate the names with values. Still, this
> doesn't address the "surprise effect" of "why this Enum doesn't have
> ::from() in it?". There doesn't exist any other value (string or otherwis=
e)
> that could be used in ::from() or ::tryFrom() in a Basic Enum, which coul=
d
> make it less contentious. Also, in the spirit of NOT making Enums "Fancy
> strings", I'm looking for ways to reconstruct my Enum and all the behavio=
rs
> available inside of it without even having to associate or think about a
> string. The only reason a string comes into the discussion is because
> $enum->value is one and is stored. I also checked and:
>
> enum Foo {
>     case 1;
>     case 2;
> }
>
> is a parse error. [6].
>
> Larry has also suggested that instead of making Basic Enum implement
> `::from()` and `::tryFrom()` we could instead offer auto-populated
> String-Backed Enum values. That means transforming this:
>
> ```
> enum Foo: string {
>     case Bar;
>     case Baz;
> }
> ```
>
> (which is a Fatal Error today) into this:
>
> enum Foo: string {
>     case Bar =3D 'Bar';
>     case Baz =3D 'Baz';
> }
>
> I also like this proposal. Although semantically, I think it would be
> better / have been better to have Basic Enum implementing the ::from()
> methods, one could argue that adding it now could be a breaking change
> since people could have Basic Enum already implementing their own custom
> ::from() method.
>
> In conclusion, the "complex" (as opposed to primitive) object Enum is not
> a Fancy String and where I'm coming from I believe to be in sync with tha=
t
> mindset. However, PHP is highly used in Web context where we may need to
> use asynchronous processes to make API calls fast and schedule executions
> at a different context which often involves serialization. As such, being
> able to reconstruct a Basic Enum seems a rather fundamental need that we
> can still make it viable by making a small `: string` change to the Enum
> and opting-in into the from / tryFrom utilities. This should not affect
> Int-Backed Enums at all.
>
> Where casing is concerned (camelCase, PascalCase, snake-case, etc) [7],
> one can argue that if you want to have full control over casing, you shou=
ld
> definitely take control over the values of your Enum. The beauty (in my
> mind) about making it default to the enum name is that it doesn't matter =
if
> I follow PER-CS rules or not, the truth is I don't need to think about
> strings at all because my Enum is not a Fancy string.
>
> I didn't intend to write such a long email, but I'm really keen on hearin=
g
> arguments against everything I shared to see if there are any flaws in my
> thought process.
>
> [1] https://wiki.php.net/rfc/enumerations#basic_enumerations
> [2] https://externals.io/message/118040
> [3] https://externals.io/message/124991
> [4] https://externals.io/message/123388
> [5] https://peakd.com/hive-168588/@crell/on-the-use-of-enums
> [6] https://3v4l.org/cDISV#v8.4.10
> [7] https://externals.io/message/123388#123394
>
> --
> Marco Deleu
>

It's important to keep in mind that when non-backed enums have a value by
default, it will be used as such. When inevitably the assumption is made
that a value can be used because it exists, and then the enum name is
changed, the "from" will break as well. If I rename a case and someone else
is using this in a database and neither of us consider the name to be
changed, we're now stuck with datacorruption and broken code. I prefer this
to remain separate as it is.

--000000000000af37cf063980093f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 9, =
2025 at 3:33=E2=80=AFPM Deleu &lt;<a href=3D"mailto:deleugyn@gmail.com">del=
eugyn@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>Hi people!</div><div><br></div><div>To=
day I tried to do `ResourceType::from()` and was surprised that my IDE imme=
diately screamed at me. After further investigation, I realized that Basic =
Enums (this is what the RFC called it [1]) does not have these commodities =
backed into them.</div><div><br></div><div>I did some digging and I found 2=
 main discussions: Stringable by default [2][3] and backed-in commodities [=
4]. I think Benjamin, Derick and Nicolas have argued why Stringable by defa=
ult may not be desirable and I only mention this for completeness of the co=
nversation. I don&#39;t want to talk about that at all. Instead, I want to =
focus on the other side: construct from string by default (from/tryFrom()).=
</div><div><br></div><div>I also read Larry&#39;s post that has been shared=
 throughout these discussions [5] and it seems fair and sound to use guardr=
ails to discourage unintended use. This gets into the territory of &quot;le=
t me do what I want, I know what I&#39;m doing&quot; vs &quot;let me limit =
what you can do because I built it and I know exactly what it was intended =
for&quot;, which I also want to try and steer away from debating, each camp=
 has its merits.</div><div><br></div><div>Bilge said:</div><div><br></div><=
blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">My que=
stion, then, is why can&#39;t basic enumerations have these semantics by de=
fault? Or, to state it more concretely, what would be the downside to havin=
g all &quot;basic&quot; enumerations actually being &quot;backed&quot; enum=
erations whose values implicitly mirror their names for the purposes of con=
verting to/from strings? Would this not make basic enumeration more useful =
without any particular downsides?</blockquote><div><br></div><div>While I&#=
39;m searching for similar clarification, I want to pose the question diffe=
rently. I feel like the answer to his question is in Larry&#39;s article ab=
out discouraging fancy strings. My question boils down purely to: <b>can Ba=
sic Enums implement ::from() / tryFrom() methods?</b></div><div><b><br></b>=
</div><div>Larry said:</div><div><br></div><blockquote style=3D"margin:0px =
0px 0px 40px;border:none;padding:0px">[...] In your case, you want to &quot=
;upcast&quot; a string to an enum. That means you&#39;re doing some sort of=
 deserialization, presumably. In that case, a backed enum is what you want.=
 <b>A unit enum isn&#39;t serializable, by design.</b></blockquote><div><di=
v><br></div><div>Although this starts to thread into very pedantic territor=
y, I think, in fact, a <b>unit enum</b>=C2=A0(assuming it means Basic enum)=
 is in fact always serializable to a string: `$enum-&gt;value`. By design, =
the value is a string and it cannot have duplicate values in a single enum.=
 It means it&#39;s extremely easy to define an Enum in PHP and at some poin=
t store it in a storage engine / database in the form of `$enum-&gt;value`.=
 Now if I want to get back my Enum at a later stage I need to implement exa=
ctly the same code that already exists in the PHP engine behind `Enum::from=
()`. Maybe it&#39;s not serializable in the sense that it doesn&#39;t imple=
ment any true serialization mechanism, which I&#39;m guessing a backed-enum=
 probably does, but I&#39;m trying to come from the very practical applicat=
ion of creating a Basic Enum at an HTTP context (which is the bread and but=
ter of PHP) and then recovering said Enum in a background worker context wi=
thout having to use PHP `serialize()` function and store PHP-specific diale=
ct in a database that is used by multiple teams and programming languages.<=
/div><div><br></div><div>I also take the point that it is easy to argue aga=
inst all this: just put `: string` on your Enum and duplicate the names wit=
h values. Still, this doesn&#39;t address the &quot;surprise effect&quot; o=
f &quot;why this Enum doesn&#39;t have ::from() in it?&quot;. There doesn&#=
39;t exist any other value (string or otherwise) that could be used in ::fr=
om() or ::tryFrom() in a Basic Enum, which could make it less contentious. =
Also, in the spirit of NOT making Enums &quot;Fancy strings&quot;, I&#39;m =
looking for ways to reconstruct my Enum and all the behaviors available ins=
ide of it without even having to associate or think about a string. The onl=
y reason a string comes into the discussion is because $enum-&gt;value is o=
ne and is stored. I also checked and:<br><br>enum Foo {</div><div>=C2=A0 =
=C2=A0 case 1;</div><div>=C2=A0 =C2=A0 case 2;</div><div>}</div><div><br></=
div><div>is a parse error. [6].</div><div><br></div><div>Larry has also sug=
gested that instead of making Basic Enum implement `::from()` and `::tryFro=
m()` we could instead offer auto-populated String-Backed Enum values. That =
means transforming this:</div><div><br></div><div>```<br>enum Foo: string {=
<br>=C2=A0 =C2=A0 case Bar;<br>=C2=A0 =C2=A0 case Baz;<br>}<br>```<br><br><=
/div><div>(which is a Fatal Error today) into this:</div><div><br></div><di=
v>enum Foo: string {<br>=C2=A0 =C2=A0 case Bar =3D &#39;Bar&#39;;<br>=C2=A0=
 =C2=A0 case Baz =3D &#39;Baz&#39;;<br>}</div><div><br></div><div>I also li=
ke this proposal. Although semantically, I think it would be better / have =
been better to have Basic Enum implementing the ::from() methods, one could=
 argue that adding it now could be a breaking change since people could hav=
e Basic Enum already implementing their own custom ::from() method.</div><d=
iv><br></div><div>In conclusion, the &quot;complex&quot; (as opposed to pri=
mitive) object Enum is not a Fancy String and where I&#39;m coming from I b=
elieve to be in sync with that mindset. However, PHP is highly used in Web =
context where we may need to use asynchronous processes to make API calls f=
ast and schedule executions at a different context which often involves ser=
ialization. As such, being able to reconstruct a Basic Enum seems a rather =
fundamental need that we can still make it viable by making a small `: stri=
ng` change to the Enum and opting-in into the from / tryFrom utilities. Thi=
s should not affect Int-Backed Enums at all.=C2=A0</div><div><br></div><div=
>Where casing is concerned (camelCase, PascalCase, snake-case, etc) [7], on=
e can argue that if you want to have full control over casing, you should d=
efinitely take control over the values of your Enum. The beauty (in my mind=
) about making it default to the enum name is that it doesn&#39;t matter if=
 I follow PER-CS rules or not, the truth is I don&#39;t need to think about=
 strings at all because my Enum is not a Fancy string.</div><div><br></div>=
<div>I didn&#39;t intend to write such a long email, but I&#39;m really kee=
n on hearing arguments against everything I shared to see if there are any =
flaws in my thought process.</div><div><br></div><div>[1]=C2=A0<a href=3D"h=
ttps://wiki.php.net/rfc/enumerations#basic_enumerations" target=3D"_blank">=
https://wiki.php.net/rfc/enumerations#basic_enumerations</a></div><div>[2]=
=C2=A0<a href=3D"https://externals.io/message/118040" target=3D"_blank">htt=
ps://externals.io/message/118040</a></div><div>[3]=C2=A0<a href=3D"https://=
externals.io/message/124991" target=3D"_blank">https://externals.io/message=
/124991</a></div><div>[4]=C2=A0<a href=3D"https://externals.io/message/1233=
88" target=3D"_blank">https://externals.io/message/123388</a></div><div>[5]=
=C2=A0<a href=3D"https://peakd.com/hive-168588/@crell/on-the-use-of-enums" =
target=3D"_blank">https://peakd.com/hive-168588/@crell/on-the-use-of-enums<=
/a></div><div>[6]=C2=A0<a href=3D"https://3v4l.org/cDISV#v8.4.10" target=3D=
"_blank">https://3v4l.org/cDISV#v8.4.10</a></div><div>[7]=C2=A0<a href=3D"h=
ttps://externals.io/message/123388#123394" target=3D"_blank">https://extern=
als.io/message/123388#123394</a></div><div><br></div><span class=3D"gmail_s=
ignature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><=
div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div></d=
iv></div></div></div></div></div></div></blockquote><div><br></div><div>It&=
#39;s important to keep in mind that when non-backed enums have a value by =
default, it will be used as such. When inevitably the assumption is made th=
at a value can be used because it exists, and then the enum name is changed=
, the &quot;from&quot; will break as well. If I rename a case and someone e=
lse is using this in a database and neither of us consider the name to be c=
hanged, we&#39;re now stuck with datacorruption and broken code. I prefer t=
his to remain separate as it is.</div></div></div>

--000000000000af37cf063980093f--