On 03/01/2021 20:45, tyson andre wrote:
__debugInfo() is a slight improvement, but the human-readable representation of
an object isn't always the same thing as the debug representation of the object.
A human-readable representation might be `Point(x: 1, y: 2)`, where var_dump or
var_export(`__set_state`)
is much longer, and I don't believe var_dump is a one size fits all solution
for both simple and recursive data structures,
especially since `__debugInfo` predates the repl.
A couple of notes on this:
- The readline-based shell for "php -a" was added in PHP 5.1
[https://www.php.net/manual/en/features.commandline.interactive.php] and
__debugInfo not until 5.6 [https://wiki.php.net/rfc/debug-info]
- I agree that the existing debug outputs are quite verbose, but I don't
think that's a problem unique to the REPL. var_export() is constrained
to render valid PHP code, but print_r() and var_dump() could and perhaps
should represent objects more compactly.
- That compact representation of a Point would be useful pretty much
everywhere anyone wanted debug output. It would also be possible to
build it on top of the existing functionality (key-value pairs from
__debugInfo if defined, else all properties).
- Allowing objects to overload the output seems much preferable to the
formatting function having to know all the special cases, so I'm not
convinced of the need to hook the entire output for the shell.
- I can't find any references off-hand, but I'm pretty sure popular
REPLs in other languages take that approach: use existing
pretty-printing mechanisms from the language, which in turn can be
overloaded by individual types / classes.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
