Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125030
Date: Sat, 17 Aug 2024 16:27:59 -0400
To: =?utf-8?Q?Rowan_Tommins_=5BIMSoP=5D?= <imsop.php@rwec.co.uk>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>
Message-ID: <428B8247-59F1-4987-B9F7-0EE7F5F70717@getmailspring.com>
In-Reply-To: <7082DD61-A257-4B3D-A49E-9CB32A560CDA@rwec.co.uk>
References: <7082DD61-A257-4B3D-A49E-9CB32A560CDA@rwec.co.uk>
Subject: Re: [PHP-DEV] String enums & __toString()
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66c107cf_74b0dc51_17d67"
From: john@coggeshall.org (John Coggeshall)

--66c107cf_74b0dc51_17d67
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


> Just to show the range of viewpoints on this, I'd like to mention my opinion that Stringable is a horrible feature, with an implementation that's completely inconsistent with the rest of the language, and no clear semantic purpose. If your contract is "the input must be usable as a string", then the obvious type to require is "string".
> I'm not saying my opinion is objectively right, or even held by a majority, I just wanted to provide a counterbalance of sorts.

I don't think it's without purpose... what it should be for is to allow developers to make flexible APIs where they can type-hint string|Stringable and the user of the API doesn't have to worry about it.
There are examples where complex data types (object, enums) can be intelligently and reasonably cast to a string for more than simply "output" purposes (e.g. print statements, log files and the like). Since we have __toString() it makes sense to me to have an interface I can type against to know that method is valid to call instead of hunting around for it with method_exists() or other some such thing. See below for an example I pulled off the top of my head with an ORM.
> >function fooThatWantsString(string|Stringable|UnitEnum $bar)
> I would have thought the more common use case would be the opposite: you want the function to be limited to a particular enum, but allow strings for backward compatibility, and have this:
> function fooThatTakesAnOption(FooOptionEnum|string $opt) {
> if ( is_string($opt) ) {
> $opt = FooOptionEnum::from($opt);
> }
> ...
> }

I think there's pretty meaningful evidence based on the engagement in the PR (and the number of likes in that PR regarding specifically at least allowing __toString() to be implemented) that your version of the mock API above and my version don't have to be mutually exclusive things -- nor is one vs. the other better or worse from a generic perspective. A composer package you pull into your project won't know the Enum type you want to pass in, but it shouldn't be hard for you to pass in a string enum if the API requires a string. There are plenty of APIs out there in the wild right now buried in various composer packages that expect a string but a string-backed enum might make sense.... I haven't tested this directly but just as an offhand example consider something like Laravel's Eloquent ORM:
$model->query()->where('enumColumn', '=', MyEnum::MYVALUE)->get();
It's possible that Laravel has already been smart enough to add the necessary logic to look for UnitEnum here and resolve that to MyEnum::MYVALUE->value , but my argument is that it shouldn't have to try that hard. Nor should I have to write MyEnum::MYVALUE->value in my query -- nor should any developer ever have to think/worry about that for a string enum with a string parameter. As a library developer when I write a method to be used by others in an entirely unknown context, if my method takes a string input then I should be able to hint string|Stringable and know I've given users of my library maximum flexibility with basically no real effort on my part (other than a redundant $foo = (string)$foo line. The fact this works 99% of the time (except, strangely, string-backed enums) is the inconsistency I want to repair here.
As it seems to me there isn't a particularly strong argument for why we don't allow __toString() , would anyone have a strong objection to getting an RFC going to get this voted on? I didn't look closely at the original PR from the "auto implement __toString()" for string-backed enums, but I think this might literally be a one-liner just to enable enums to implement __toString() and the rest can be tossed.
John
--66c107cf_74b0dc51_17d67
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><blockquote><div><div>Just to show the range of viewpoints on this, I=
'd like to mention my opinion that Stringable is a horrible feature, with=
 an implementation that's completely inconsistent with the rest of the la=
nguage, and no clear semantic purpose. If your contract is =22the input m=
ust be usable as a string=22, then the obvious type to require is =22stri=
ng=22.</div><br><div>I'm not saying my opinion is objectively right, or e=
ven held by a majority, I just wanted to provide a counterbalance of sort=
s.</div><br></div></blockquote><div><br><div>I don't think it's without p=
urpose... what it <em>should</em>&nbsp; be for is to allow developers to =
make flexible APIs where they can type-hint <code>string=7CStringable</co=
de>&nbsp; and the user of the API doesn't have to worry about it.</div><b=
r><div>There are examples where complex data types (object, enums) can be=
 intelligently and reasonably cast to a string for more than simply =22ou=
tput=22 purposes (e.g. print statements, log files and the like). Since w=
e have <code>=5F=5FtoString()</code>&nbsp; it makes sense to me to have a=
n interface I can type against to know that method is valid to call inste=
ad of hunting around for it with <code>method=5Fexists()</code>&nbsp; or =
other some such thing. See below for an example I pulled off the top of m=
y head with an ORM.</div><br><blockquote>&gt;function fooThatWantsString(=
string=7CStringable=7CUnitEnum =24bar)</blockquote><blockquote></blockquo=
te><blockquote>I would have thought the more common use case would be the=
 opposite: you want the function to be limited to a particular enum, but =
allow strings for backward compatibility, and have this:</blockquote><blo=
ckquote></blockquote><blockquote>function fooThatTakesAnOption(=46ooOptio=
nEnum=7Cstring =24opt) =7B</blockquote><blockquote>if ( is=5Fstring(=24op=
t) ) =7B</blockquote><blockquote>=24opt =3D =46ooOptionEnum::from(=24opt)=
;</blockquote><blockquote>=7D</blockquote><blockquote>...</blockquote><bl=
ockquote>=7D</blockquote><br><div>I think there's pretty meaningful evide=
nce based on the engagement in the PR (and the number of likes in that PR=
 regarding specifically at least allowing <code>=5F=5FtoString()</code>&n=
bsp; to be implemented) that your version of the mock API above and my ve=
rsion don't have to be mutually exclusive things -- nor is one vs. the ot=
her better or worse from a generic perspective. A composer package you pu=
ll into your project won't know the Enum type you want to pass in, but it=
 shouldn't be hard for you to pass in a string enum if the API requires a=
 string.&nbsp; There are plenty of APIs out there in the wild right now b=
uried in various composer packages that expect a <code>string</code>&nbsp=
; but a string-backed enum might make sense.... I haven't tested this dir=
ectly but just as an offhand example consider something like Laravel's El=
oquent ORM:</div><br><div><code>=24model-&gt;query()-&gt;where('enumColum=
n', '=3D', MyEnum::MYVALUE)-&gt;get();</code>&nbsp;</div><br><div>It's po=
ssible that Laravel has already been smart enough to add the necessary lo=
gic to look for <code>UnitEnum</code>&nbsp; here and resolve that to <cod=
e>MyEnum::MYVALUE-&gt;value</code>&nbsp;, but my argument is that it shou=
ldn't have to try that hard. Nor should I have to write <code>MyEnum::MYV=
ALUE-&gt;value</code>&nbsp; in my query -- nor should any developer ever =
have to think/worry about that for a string enum with a string parameter.=
 As a library developer when I write a method to be used by others in an =
entirely unknown context, if my method takes a string input then I should=
 be able to hint <code>string=7CStringable</code>&nbsp; and know I've giv=
en users of my library maximum flexibility with basically no real effort =
on my part (other than a redundant <code>=24foo =3D (string)=24foo</code>=
&nbsp; line. The fact this works 99% of the time (except, strangely, stri=
ng-backed enums) is the inconsistency I want to repair here.</div><br><di=
v>As it seems to me there isn't a particularly strong argument for why we=
 don't allow <code>=5F=5FtoString()</code>&nbsp;, would anyone have a str=
ong objection to getting an R=46C going to get this voted on=3F I didn't =
look closely at the original PR from the =22auto implement =5F=5FtoString=
()=22 for string-backed enums, but I think this might literally be a one-=
liner just to enable enums to implement <code>=5F=5FtoString()</code>&nbs=
p; and the rest can be tossed.</div><br><div>John</div></div>
--66c107cf_74b0dc51_17d67--