Re: [RFC] var_representation() : readable alternative to var_export()

Hi Rowan Tommins, > > Hi internals, > > > > I've > > created https://wiki.php.net/rfc/readable_var_representation based > > on > > my original proposal in > > https://externals.io/message/112924 > > > > This RFC proposes adding a new function var_representation(mixed $value, > > int $flags=0): string > > My hesitation remains that this is just duplicating existing > functionality with only cosmetic differences. > > As a user of PHP 8.1, how would I decide whether to use print_r, > var_dump, var_export, or var_representation? > > And under what circumstances would I bother to write > "var_representation($var, VAR_REPRESENTATION_SINGLE_LINE);"? You have a good point on needing to document the circumstances where this would be useful. I meant to write up the reasons where an end user would or wouldn't want this functionality - it's useful when reviewing or voting on the RFC. I've added those to https://wiki.php.net/rfc/readable_var_representation#when_would_a_user_use_var_representation , including when I think the VAR_REPRESENTATION_SINGLE_LINE flag would be useful to users. var_representation may be useful to a user when any of the following apply: - You are generating a snippet of code to eval() in a situation where the snippet will occasionally or frequently be read by a human (If the output never needs to be read by a human, return unserialize(' . var_export(serialize($data), true) . '); can be used) - The output is occasionally or frequently read by humans (e.g. CLI or web app output, a REPL, unit test output, etc.). - The output contains control characters such as newlines, tabs, \r or \x00 and may be viewed or edited by other users in a text editor/IDE. Many IDEs may convert from windows line endings (\r\n) to unix line endings(\n) automatically. - You want to unambiguously see control characters in the raw output regardless of how likely they are (e.g. dumping php ini settings, debugging mysterious test failures, etc) - You are writing unit tests for applications supporting PHP 8.1+ (or a var_representation polyfill) that test the exact string representation of the output (e.g. phpt tests of php-src and PECL extensions) - You need to copy the output into a codebase that's following a modern coding style guideline such as modern coding guidelines such as PSR-2. It also saves time if you don't have to remove array keys of lists and convert array() to []. (I added that and a section on when/why a user may decide to use VAR_REPRESENTATION_SINGLE_LINE in the RFC) As for print_r() - https://www.php.net/print_r seems underdocumented - It doesn't mention how booleans, null, and floats are represented (same as print()) except in user notes. The online documentation for var_export/var_dump explains what they do but not why/when they would be used, it may be worthwhile to submit a PR to expand on those. Regards, Tyson