Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125005
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 17 Aug 2024 00:49:05 +0200
To: "John Coggeshall" <john@coggeshall.org>, Bilge <bilge@scriptfusion.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <bd71f612-61de-4682-9ffc-6a3400086649@app.fastmail.com>
In-Reply-To: <59BED9FD-EB77-4B44-9F93-7FC573EC7F14@getmailspring.com>
References: <501db7d2-55e1-4b20-bb6e-1e079aa4939b@scriptfusion.com>
 <59BED9FD-EB77-4B44-9F93-7FC573EC7F14@getmailspring.com>
Subject: Re: [PHP-DEV] String enums & __toString()
Content-Type: multipart/alternative;
 boundary=b78e722581454cd8af08e7da36f61c29
From: rob@bottled.codes ("Rob Landers")

--b78e722581454cd8af08e7da36f61c29
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Aug 16, 2024, at 21:57, John Coggeshall wrote:
>> Didja really?
>>=20
>> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_=
enums
> I swear I did. <shame>
>=20
> That said, looking at that RFC it's a slightly different take than wha=
t I am suggesting. This RFC suggests that `string`  enums automatically =
implement `Stringable` . I am pointing out that it's a little silly IMO =
that we don't allow `__toString()`  at all and let the developer choose =
if they want to implement `Stringable` . Looking through the PR comments=
 it's pretty clear there was a decent amount of support for this alterna=
tive idea. It also looks like the PR for this died on the vine and I'm c=
urious is there is any interest in reviving the discussion?
>=20
> I'm not seeing an obvious upside to forbidding straight out `__toStrin=
g()` , especially (as is pointed out in the PR comments) that you can us=
e other native interfaces like `JsonSerializable`  without issue.

Hello,

I personally find it an interesting design choice. I agree with it, and =
disagree with it at the same time. Like, anytime I find myself wanting t=
o reach for enums as strings, I realize I want a constant instead. But t=
hen someone sees a string type and manually types it instead of using th=
e constant (heh, I=E2=80=99ve been guilty of that myself a few times).

That being said, I would like to be able to use | and & on integer enums=
 more than I would strings as stringables. Something like =E2=80=9Cflags=
=E2=80=9D mode in C#. Maybe even make =E2=80=9Cflag=E2=80=9D a backing t=
ype of enums. It would make a ton of json flags much simpler to reason a=
bout (and filters/sanitizers).



=E2=80=94 Rob
--b78e722581454cd8af08e7da36f61c29
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}=0Ap.MsoNormal,p.MsoNoSpacing{margin:0}</=
style></head><body><div><br></div><div><br></div><div>On Fri, Aug 16, 20=
24, at 21:57, John Coggeshall wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><blockquote><div><div>Didja really?<br></div><div><=
br></div><div><a href=3D"https://wiki.php.net/rfc/auto-implement_stringa=
ble_for_string_backed_enums" title=3D"https://wiki.php.net/rfc/auto-impl=
ement_stringable_for_string_backed_enums">https://wiki.php.net/rfc/auto-=
implement_stringable_for_string_backed_enums</a><br></div></div></blockq=
uote><div><div>I swear I did. &lt;shame&gt;<br></div><div><br></div><div=
>That said, looking at that RFC it's a slightly different take than what=
 I am suggesting. This RFC suggests that <code>string</code>&nbsp; enums=
 automatically implement <code>Stringable</code>&nbsp;. I am pointing ou=
t that it's a little silly IMO that we don't allow <code>__toString()</c=
ode>&nbsp; at all and let the developer choose if they want to implement=
 <code>Stringable</code>&nbsp;. Looking through the PR comments it's pre=
tty clear there was a decent amount of support for this alternative idea=
. It also looks like the PR for this died on the vine and I'm curious is=
 there is any interest in reviving the discussion?<br></div><div><br></d=
iv><div>I'm not seeing an obvious upside to forbidding straight out <cod=
e>__toString()</code>&nbsp;, especially (as is pointed out in the PR com=
ments) that you can use other native interfaces like <code>JsonSerializa=
ble</code>&nbsp; without issue.<br></div></div></blockquote><div><br></d=
iv><div>Hello,<br></div><div><br></div><div>I personally find it an inte=
resting design choice. I agree with it, and disagree with it at the same=
 time. Like, anytime I find myself wanting to reach for enums as strings=
, I realize I want a constant instead. But then someone sees a string ty=
pe and manually types it instead of using the constant (heh, I=E2=80=99v=
e been guilty of that myself a few times).<br></div><div><br></div><div>=
That being said, I would like to be able to use | and &amp; on integer e=
nums more than I would strings as stringables. Something like =E2=80=9Cf=
lags=E2=80=9D mode in C#. Maybe even make =E2=80=9Cflag=E2=80=9D a backi=
ng type of enums. It would make a ton of json flags much simpler to reas=
on about (and filters/sanitizers).<br></div><div><br></div><div><br></di=
v><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body>=
</html>
--b78e722581454cd8af08e7da36f61c29--