On 23/01/2021 21:07, tyson andre wrote:
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]