Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129542
Precedence: list
MIME-Version: 1.0
Date: Thu, 04 Dec 2025 10:37:46 +0100
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] Stringable Enums
In-Reply-To: <3D90E174-23F2-4B90-B881-20A0AD30CF0C@rwec.co.uk>
References: <CALaXqqQbt-mkXzi1-UZoJ7+ToQ_+izPCm8oc2hmvHZB-9L56YQ@mail.gmail.com>
 <3D90E174-23F2-4B90-B881-20A0AD30CF0C@rwec.co.uk>
Message-ID: <31ed0152483193e85ca3a9eebc5e6d14@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-12-04 09:01, schrieb Rowan Tommins [IMSoP]:
> My first instinct was that this was dragging up a discussion we've had 
> lots of times, but your examples make clear that you are *not* just 
> talking about converting enums to their backing value.
> 
> On the other hand, that does make me wonder: in what way is 
> (string)$foo clearer than $foo->toString() for those use cases? In my 
> experience, it just makes the functionality less discoverable - people 
> don't think to try (string)$exception or (string)$simpleXmlNode, so 
> miss that those have specific behaviour.
> 
> And is it even a good name for those methods? In the date-time package, 
> for instance, it would be better named toEnglishName() or 
> getFullEnglishName(), as its docblock explicitly says. In the framework 
> code, it seems to be used for a property called $displayValue, so the 
> obvious name for the method would be getDisplayValue().

I fundamentally disagree with the proposal for reasons similar to those 
that Rowan mentioned. More specifically, I consider implementing 
`__toString()` to be a mistake, unless it is for a debug representation. 
There rarely is a single (or primary), obvious and parameter-less string 
representation for a given object.

There might be one for enums, since they can't hold state, but as the 
previous RFCs indicated, folks generally expect it to just be the enum's 
value which then just encourages folks to treat enums as “fancy strings” 
or “fancy class constants” rather a proper data type unto itself even 
more than they already do, where it's `->value` all the time. And with 
the planned enhancements of enums into full tagged unions, I'd also 
rather not make decisions now that we might regret later when actually 
extending enums to tagged unions.

Best regards
Tim Düsterhus