Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125014
Date: Fri, 16 Aug 2024 20:47:20 -0400
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Message-ID: <82BB4B15-F799-4E11-8A0F-CF5E5C995F82@getmailspring.com>
In-Reply-To: <a3a25f80-6179-4bf6-a3bc-ebd14ab5f5ee@app.fastmail.com>
References: <a3a25f80-6179-4bf6-a3bc-ebd14ab5f5ee@app.fastmail.com>
Subject: Re: [PHP-DEV] String enums & __toString()
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66bff318_643c9869_17d67"
From: john@coggeshall.org (John Coggeshall)

--66bff318_643c9869_17d67
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> To the original question, there's two reasons that __toString() was deliberately omitted from enums:
>
> 1. To discourage their use as "fancy strings". Enums are their own type, independent of any other. Making them usable as 95% strings partially defeats their purpose.

I disagree with the idea that we need to take this extreme of a stance when it comes to the notion of protecting the developer from themselves. There are a lot of really value use cases where it makes sense to have a string-backed enum . Not allowing developers to cast it to a string isn't doing anything but making people type $enum->value instead of (string)$enum -- so if someone wants to defeat their purpose this isn't stopping them. It is, however, making the language inconsistent because I literally have a enumeration defined by strings and there is literally no way to make PHP treat it like a string. This makes APIs sloppy imo because consider something like this:
function foo(string|Stringable $bar) {}
Because of these limitations this blows up into a much uglier thing in order accomplish what IMO should be a straightforward task:
function fooThatWantsString(string|Stringable|UnitEnum $bar)
{
if(($bar instanceof UnitEnum) && !is_string($bar->value)) {
throw InvalidArgumentException('This is exactly the sort of thing we are trying to get rid of with type hinting');
} else {
$bar = $bar->value;
}

$bar = (string)$bar;
}

Of course, you could also pass $bar->value higher up the call stack but it's much cleaner IMO to let the function call be smart enough to typecast as necessary. What's the point of a Stringable interface if we can't actually implement __toString() for it? Note again we can implement JsonSerializable and nothing complains when enum serializes to a simple string.
> 2. We still intend to add associated values to enums at some point (aka ADTs, aka tagged unions), and... we're not really sure yet if that will impact __toString() at all. It may, it may not, we don't know. So for now we're keeping our options open by disallowing __toString(), in case it ends up being needed for some ADT-related behavior in the future.
__toString() should return a string, if an enum literally represents a string constant it makes zero sense for it to ever return anything but that string constant. I don't think this is something ADTs or tagged unions or anything of the sort should play a role in deciding.
John
--66bff318_643c9869_17d67
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<blockquote><div><div>To the original question, there's two reasons that =
=5F=5FtoString() was deliberately omitted from enums:</div><br><div>1. To=
 discourage their use as =22fancy strings=22. Enums are their own type, i=
ndependent of any other. Making them usable as 95% strings partially defe=
ats their purpose.</div></div></blockquote><div><br><div>I disagree with =
the idea that we need to take this extreme of a stance when it comes to t=
he notion of protecting the developer from themselves. There are a lot of=
 really value use cases where it makes sense to have a string-backed <cod=
e>enum</code>&nbsp;. Not allowing developers to cast it to a string isn't=
 doing anything but making people type <code>=24enum-&gt;value</code>&nbs=
p; instead of <code>(string)=24enum</code>&nbsp; -- so if someone wants t=
o defeat their purpose this isn't stopping them. It is, however, making t=
he language inconsistent because I literally have a enumeration defined b=
y strings and there is literally no way to make PHP treat it like a strin=
g. This makes APIs sloppy imo because consider something like this:</div>=
<br><div>function foo(string=7CStringable =24bar) =7B=7D</div><br><div>Be=
cause of these limitations this blows up into a much uglier thing in orde=
r accomplish what IMO should be a straightforward task:</div><br><div>fun=
ction fooThatWantsString(string=7CStringable=7CUnitEnum =24bar)</div><div=
>=7B</div><div>&nbsp;&nbsp;&nbsp;&nbsp; if((=24bar instanceof UnitEnum) &=
amp;&amp; =21is=5Fstring(=24bar-&gt;value)) =7B</div><div>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw InvalidArgumentExcept=
ion('This is exactly the sort of thing we are trying to get rid of with t=
ype hinting');</div><div>&nbsp;&nbsp;&nbsp;&nbsp; =7D else =7B</div><div>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =24bar =3D =24bar-=
&gt;value;</div><div>&nbsp;&nbsp;&nbsp;&nbsp; =7D</div><br><div>&nbsp;&nb=
sp;&nbsp;&nbsp; =24bar =3D (string)=24bar;</div><div>=7D</div><br><div>Of=
 course, you could also pass =24bar-&gt;value higher up the call stack bu=
t it's much cleaner IMO to let the function call be smart enough to typec=
ast as necessary. What's the point of a <code>Stringable</code>&nbsp; int=
erface if we can't actually implement =5F=5FtoString() for it=3F Note aga=
in we can implement <code>JsonSerializable</code>&nbsp; and nothing compl=
ains when <code>enum</code>&nbsp; serializes to a simple string.</div><br=
><blockquote>2. We still intend to add associated values to enums at some=
 point (aka ADTs, aka tagged unions), and... we're not really sure yet if=
 that will impact =5F=5FtoString() at all. It may, it may not, we don't k=
now. So for now we're keeping our options open by disallowing =5F=5FtoStr=
ing(), in case it ends up being needed for some ADT-related behavior in t=
he future.</blockquote><br><div>=5F=5FtoString() should return a string, =
if an enum literally represents a string constant it makes zero sense for=
 it to ever return anything but that string constant. I don't think this =
is something ADTs or tagged unions or anything of the sort should play a =
role in deciding.</div><br><div>John</div></div>
--66bff318_643c9869_17d67--