On Fri, Aug 16, 2024, at 21:57, John Coggeshall wrote: >> Didja really? >> >> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums > I swear I did. <shame> > > That said, looking at that RFC it's a slightly different take than what 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 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? > > I'm not seeing an obvious upside to forbidding straight out `__toString()` , > especially (as is pointed out in the PR comments) that you can use 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 to reach for enums as strings, I realize I want a constant instead. But then someone sees a string type and manually types it instead of using the constant (heh, I’ve 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 “flags” mode in C#. Maybe even make “flag” a backing type of enums. It would make a ton of json flags much simpler to reason about (and filters/sanitizers). — Rob
