Hi Sara Golemon and Rowan Tommins, > > On 20/01/2021 20:21, Claude Pache wrote: > > > Or `short_var_export()` could just reuse the existing `__debugInfo()` > > > magic method (which is already used by both `var_dump()` and > > > `print_r`, but not by `var_export()`). The programmer would just need > > > to make sure that `__set_state()` can consume the array produced by > > > `__debugInfo()`. > > > > > > This is an interesting question to explore, but I don't follow how this > > relates to my previous e-mail. I'm saying that having print_r, var_dump, > > var_export, and var_export_short (or whatever we call it) all in one > > language is more confusing than helpful. > > > > > IMO print_r/var_dump should be kept out of this discussion. Those are human > readable outputs for human consumption. var_export() is about a machine > readable output for recreating initial state within a runtime. The > requirements presented are wholly different.
Even python has str(), repr(), and a separate https://docs.python.org/3/library/pprint.html module for pretty printing, and https://docs.python.org/3/library/reprlib.html I'd agree with leaving out print_r/var_dump out of this - using `__debugInfo()` in a manner it isn't intended for and passing different arrays to `__set_state` in var_export and short_var_export/var_representation would be an inconsistency I'd find surprising and inconsistent as an end user. Even as a machine-readable output, var_export has limitations but there's resistance to changing it and a lot of pre-existing code depending on its current behavior - it predates namespaces so there's no leading backslash, the output is much longer than it needs to be and takes longer to generate if the output is saved somewhere or sent over the network (e.g. million-element array with keys and indentation) As for print_r(), my stance is that the limitations of print_r() should be documented on php.net with alternatives recommended, (false, null, and the empty string all become the empty string, for example) and I avoid using it for new code, but there's not a compelling reason to remove it at the time - doing so would just be a barrier to upgrading -Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
