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

Reply via email to