Hi internals,
I'd like to start the discussion for a new RFC about removing the
prohibition on __debugInfo() methods on enums.
- RFC: https://wiki.php.net/rfc/debugable-enums
- Implementation: https://github.com/php/php-src/pull/21425
This is a replacement of my earlier RFC to allow __toString() based on the
feedback in that discussion, see
https://news-web.php.net/php.internals/129540.
Thanks,
-Daniel
Hi internals,
I'd like to start the discussion for a new RFC about removing the
prohibition on __debugInfo() methods on enums.
- RFC: https://wiki.php.net/rfc/debugable-enums
- Implementation: https://github.com/php/php-src/pull/21425
This is a replacement of my earlier RFC to allow __toString() based on
the feedback in that discussion, see
https://news-web.php.net/php.internals/129540.Thanks,
-Daniel
I'm not entirely sure this has much value, but it also seems to not have much downside. The main argument I could see for holding off is that whenever it is we get to ADTs, we may want a more complex default implementation. But that would still presumably allow being overridden, like any other class, so it doesn't seem like a landmine to me. This doesn't have the same semantic issues that __toString() has (and have been discussed elsewhere).
--Larry Garfield
Hi Daniel
On Fri, Mar 13, 2026 at 1:06 AM Daniel Scherzer
daniel.e.scherzer@gmail.com wrote:
I'd like to start the discussion for a new RFC about removing the prohibition on __debugInfo() methods on enums.
- RFC: https://wiki.php.net/rfc/debugable-enums
- Implementation: https://github.com/php/php-src/pull/21425
The RFC currently only mentions:
var_dump(Foo::Bar); // produces an array with "Bar is a case of the Foo enum"
But it would be good for it to spell out the full output for the
examples. From the implementation, I can see:
object(Foo)#%d (1) {
[0]=>
string(14) "Foo::Bar = Baz"
}
I think the enum(Foo::Bar) header should be preserved. If the user
wants to print some ancillary data for some reason, I wouldn't object
to that.
Ilija