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
