Hi Rowan Tommins, > > **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.
I mentioned php-src test cases a use case for **something that fixes the problems with var_export** and would make it possible to write shorter phpt tests (input+output) that continue to unambiguously represent output. > > 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? I meant that **changing the output format of print_r and var_dump** should be "left out of this" RFC discussion. Yes, I would agree that new or refactored phpt test cases could start using var_representation instead of var_dump if this was added to the language and authors preferred it. > 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? The use case of "generate a (short, readable, escaped) representation of a variable that can be evaluated" is something I'd consider useful enough on its own, a useful primitive in a modern programming language, and not need to cover every use case. I don't plan to change the direction of this RFC. The main features I remember unique to var_dump are as follows (I don't plan to add any of those): 1. var_dump includes object ids, this is useful for telling that objects are different - if you need to know if objects are equivalent use var_dump or debug_zval_dump or serialize. 2. String lengths- this is less of a concern with ascii control characters escaped in var_representation. 3. Prefixing scalars with types - only useful for tutorials introducing the type system or debugging 4. References and recursion - I don't think there's much demand for a predictable/readable/efficient way to represent that in a readable string. `unserialize()` covers that. > > 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. If a php developer is learning the language through php's official manual, official language reference, or through an online tutorial, that would have sections showing the different scalar types, examples involving objects and/or arrays, etc. Those use var_export/var_dump https://www.php.net/manual/en/functions.anonymous.php https://www.php.net/manual/en/language.types.string.php https://www.php.net/manual/en/language.types.boolean.php https://www.php.net/manual/en/language.types.object.php ``` <?php var_dump((bool) ""); // bool(false) var_dump((bool) 1); // bool(true) var_dump((bool) -2); // bool(true) ``` ``` <?php $obj = (object) array('1' => 'foo'); var_dump(isset($obj->{'1'})); // outputs 'bool(true)' as of PHP 7.2.0; 'bool(false)' previously var_dump(key($obj)); // outputs 'string(1) "1"' as of PHP 7.2.0; 'int(1)' previously ``` > > 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. And people who don't prefer that formatting are free to continue using var_export in their projects. If people may not prefer that formatting, that would be a reason for introducing a new function instead of modifying var_export. Imagining that var_export was never added to the language with those arbitrary formatting decisions in PHP 4.2.0 and an RFC was being discussed to add the **first** built-in way to convert a string to a machine-readable language in PHP 8.1: Would we really choose the indentation var_export used? Would we advocate putting values on different lines from keys being aware of common coding standards? Would we use `array (` with a space instead of `[`? > 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. Minor changes to var_export and var_dump have been proposed in the past and met with some hesitance or opposition to any output format changes, e.g. the question of whether changing the default output format is worth affecting existing libraries/applications/tests. https://externals.io/message/106674#106684 https://externals.io/message/101883 I would be in favor of adding string escaping to var_dump, but that is a discussion that should be "left out of this" RFC as var_dump has a different purpose. Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
