Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127970
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 9 Jul 2025 10:29:23 -0300
Message-ID: <CADK1yXLAOgDNrXO1-t0vLKCtV2qB4L2x50JFHXxJHoUrA6GPsA@mail.gmail.com>
Subject: [PHP-DEV] ::from() and tryFrom() on Basic Enums
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d54f4506397f12b5"
From: deleugyn@gmail.com (Deleu)

--000000000000d54f4506397f12b5
Content-Type: text/plain; charset="UTF-8"

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 Nicolas
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 discussions
[5] and it seems fair and sound to use guardrails to discourage unintended
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 away
from debating, each camp has its merits.

Bilge said:

My question, then, is why can't basic enumerations have these semantics by
default? Or, to state it more concretely, what would be the downside to
having all "basic" enumerations actually being "backed" enumerations whose
values implicitly mirror their names for the purposes of converting to/from
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 question
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 string
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 code
that already exists in the PHP engine behind `Enum::from()`. Maybe it's not
serializable in the sense that it doesn't implement any true serialization
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 an
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 otherwise)
that could be used in ::from() or ::tryFrom() in a Basic Enum, which could
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 behaviors
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 = 'Bar';
    case Baz = '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 that
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 should
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 hearing
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

--000000000000d54f4506397f12b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi people!</div><div><br></div><div>Today I tried to =
do `ResourceType::from()` and was surprised that my IDE immediately screame=
d 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 the=
m.</div><div><br></div><div>I did some digging and I found 2 main discussio=
ns: Stringable by default [2][3] and backed-in commodities [4]. I think Ben=
jamin, Derick and Nicolas have argued why Stringable by default may not be =
desirable and I only mention this for completeness of the conversation. I d=
on&#39;t want to talk about that at all. Instead, I want to focus on the ot=
her 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 the=
se discussions [5] and it seems fair and sound to use guardrails to discour=
age unintended use. This gets into the territory of &quot;let 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;, whic=
h 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 styl=
e=3D"margin:0 0 0 40px;border:none;padding:0px">My question, then, is why c=
an&#39;t basic enumerations have these semantics by default? Or, to state i=
t more concretely, what would be the downside to having all &quot;basic&quo=
t; enumerations actually being &quot;backed&quot; enumerations whose values=
 implicitly mirror their names for the purposes of converting to/from strin=
gs? Would this not make basic enumeration more useful without any particula=
r downsides?</blockquote><div><br></div><div>While I&#39;m searching for si=
milar clarification, I want to pose the question differently. I feel like t=
he answer to his question is in Larry&#39;s article about discouraging fanc=
y strings. My question boils down purely to: <b>can Basic Enums implement :=
:from() / tryFrom() methods?</b></div><div><b><br></b></div><div>Larry said=
:</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:none;pa=
dding:0px">[...] In your case, you want to &quot;upcast&quot; a string to a=
n enum. That means you&#39;re doing some sort of deserialization, presumabl=
y. In that case, a backed enum is what you want. <b>A unit enum isn&#39;t s=
erializable, by design.</b></blockquote><div><div><br></div><div>Although t=
his starts to thread into very pedantic territory, I think, in fact, a <b>u=
nit enum</b>=C2=A0(assuming it means Basic enum) is in fact always serializ=
able to a string: `$enum-&gt;value`. By design, the value is a string and i=
t cannot have duplicate values in a single enum. It means it&#39;s extremel=
y easy to define an Enum in PHP and at some point store it in a storage eng=
ine / 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 exactly the same code that alr=
eady exists in the PHP engine behind `Enum::from()`. Maybe it&#39;s not ser=
ializable in the sense that it doesn&#39;t implement 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 application of creating a Basic Enu=
m at an HTTP context (which is the bread and butter of PHP) and then recove=
ring said Enum in a background worker context without having to use PHP `se=
rialize()` function and store PHP-specific dialect in a database that is us=
ed by multiple teams and programming languages.</div><div><br></div><div>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=
&#39;t address the &quot;surprise effect&quot; of &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 ::from() or ::tryFrom() in a Ba=
sic 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 reconst=
ruct my Enum and all the behaviors available inside of it without even havi=
ng to associate or think about a string. The only reason a string comes int=
o the discussion is because $enum-&gt;value is one and is stored. I also ch=
ecked 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 suggested that instead of makin=
g Basic Enum implement `::from()` and `::tryFrom()` we could instead offer =
auto-populated String-Backed Enum values. That means transforming this:</di=
v><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><div>enum Foo: string {<br>=C2=
=A0 =C2=A0 case Bar =3D &#39;Bar&#39;;<br>=C2=A0 =C2=A0 case Baz =3D &#39;B=
az&#39;;<br>}</div><div><br></div><div>I also like this proposal. Although =
semantically, I think it would be better / have been better to have Basic E=
num implementing the ::from() methods, one could argue that adding it now c=
ould be a breaking change since people could have Basic Enum already implem=
enting their own custom ::from() method.</div><div><br></div><div>In conclu=
sion, the &quot;complex&quot; (as opposed to primitive) object Enum is not =
a Fancy String and where I&#39;m coming from I believe to be in sync with t=
hat mindset. However, PHP is highly used in Web context where we may need t=
o 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 ca=
n 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-Bac=
ked Enums at all.=C2=A0</div><div><br></div><div>Where casing is concerned =
(camelCase, PascalCase, snake-case, etc) [7], one can argue that if you wan=
t to have full control over casing, you should definitely take control over=
 the values of your Enum. The beauty (in my mind) about making it default t=
o the enum name is that it doesn&#39;t matter if I follow PER-CS rules or n=
ot, 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 keen on hearing arguments agai=
nst 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"https://wiki.php.net/rfc/enu=
merations#basic_enumerations">https://wiki.php.net/rfc/enumerations#basic_e=
numerations</a></div><div>[2]=C2=A0<a href=3D"https://externals.io/message/=
118040">https://externals.io/message/118040</a></div><div>[3]=C2=A0<a href=
=3D"https://externals.io/message/124991">https://externals.io/message/12499=
1</a></div><div>[4]=C2=A0<a href=3D"https://externals.io/message/123388">ht=
tps://externals.io/message/123388</a></div><div>[5]=C2=A0<a href=3D"https:/=
/peakd.com/hive-168588/@crell/on-the-use-of-enums">https://peakd.com/hive-1=
68588/@crell/on-the-use-of-enums</a></div><div>[6]=C2=A0<a href=3D"https://=
3v4l.org/cDISV#v8.4.10">https://3v4l.org/cDISV#v8.4.10</a></div><div>[7]=C2=
=A0<a href=3D"https://externals.io/message/123388#123394">https://externals=
.io/message/123388#123394</a></div><div><br></div><span class=3D"gmail_sign=
ature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" data=
-smartmail=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></div></div></div></div></div></div></div>

--000000000000d54f4506397f12b5--