On 23/01/2021 21:07, tyson andre wrote:
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.
Thanks, it's good to at least know your opinion on this, even if I don't
fully agree with it. :)
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)
As far as I know I have never had any reason to generate code and then
eval() it, and can't think of a situation where I ever would. If I
wanted a machine-readable output from a variable, I would use
serialize() or json_encode().
That's not to say that there aren't cases where those requirements do
happen, but I think it is a very niche use case to dedicate two
different built-in functions to.
- 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)
Since test output doesn't need to be executable, I would have thought
var_dump would be more appropriate than var_export here.
Checking on php-src master, this does seem to be the case in the
majority of tests:
- var_export appears 703 times in 136 different *.phpt files (0.8% of files)
- print_r appears 827 times in 342 different *.phpt files (2.1% of files)
- var_dump appears 33503 times in 9599 different *.phpt files (59.7% of
files)
So if we want to improve anything for that use case, we need to improve
or replace var_dump, not var_export.
- 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 [].
Trying to match any particular coding style seems rather outside the
remit of a built-in function - do we need flags for tabs vs spaces,
trailing commas, etc, etc? Surely it's simpler for users to take the
existing var_export format and use their IDE or dev scripts to re-format
it to taste.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php