On 24/01/2021 16:17, tyson andre wrote:
Even if a developer such as yourself doesn't need to generate code and don't expect to directly use it, **some of the applications and libraries they do use everyday would need to generate human and machine readable code.**
Sure, I believe you that there are use cases for a function that exports PHP code. I remain unconvinced that there is a need to have *two* functions for that purpose, which differ only in a few cosmetic details.
**php-src phpt tests are for tests of php itself, which puts strict and atypical limitations on the test framework.** php-src's phpt test framework may represent needs of php-src and some pecl maintainers, not userland.
I'm not sure what point you're trying to make here. You were the one that mentioned php-src tests as a use case, so I looked to see what they currently use; the answer is *overwhelmingly* var_dump.
Still, I would prefer using var_representation over var_dump in phpt for many use cases, especially with VAR_REPRESENTATION_SINGLE_LINE available.
In the previous thread, you agreed with Sara that var_dump should be "left out of this". Are you now saying that the new function *should* replace some uses of var_dump?
If that is an aim, should we look at what other differences there are between var_dump and var_export, and how we can make this new function cover more use cases?
For a new developer, they may not have those features or plugins installed in their IDE, or may not be aware of the existence of the shortcut/command to invoke those features on a range.
I contend that a new developer would very rarely have any need to use this functionality at all.
Additionally, scripts to reindent may not remove the `0 =>`, `1 =>`, etc, either not containing a php parser or assuming the user deliberately added those keys.
And maybe they'd be right not to - that's an unavoidable problem with any formatter, it won't be universal.
And that is why I'm sceptical of this function: it seems to be mostly a different set of arbitrary formatting decisions, which some people will prefer and some won't.
The only part that feels like fundamental value is escaping control characters, which could be added to var_dump and/or var_export and only affect that minority of a minority of usages which are relying on the exact output in cases where control characters are present.
Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
