Hi internals, I've created a PR https://github.com/php/php-src/pull/6619 to add an alternative to var_export(). The proposed short_var_export() also outputs/returns a parseable representation of a variable, but adds requested features for var_export.
1. Use `null` instead of `NULL` - the former is recommended by more coding guidelines (https://www.php-fig.org/psr/psr-2/). 2. Change the way indentation is done for arrays/objects. See ext/standard/tests/general_functions/short_var_export1.phpt (e.g. always indent with 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as `"[\n 'item1',\n]"` rather than `"array(\n 0 => 'item1',\n)"` 4. Prepend `\` to class names so that generated code snippets can be used in namespaces (e.g. with eval()) without any issues. 5. Support opt-in `SHORT_VAR_EXPORT_SINGLE_LINE` in `int $flags`. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. (`"['item']"`) Changing var_export() itself has been proposed 9 months ago (https://externals.io/message/109415) but the RFC discussion seems to be on hold. https://externals.io/message/106674#106684 suggested adding a new function as an alternative. One of the major objections is that changing var_export() (instead of adding a new function) would have these drawbacks: 1. It would be impractical to backport/polyfill calls with 3 args to older php versions, if `int $flags` was added. ArgumentCountErrors are thrown in php 8.0 for too many parameters, and earlier php versions warn 2. If defaults were changed, then thousands of unit tests in php-src and other projects may fail due to tests expecting the exact representation of a variable, requiring a lot of work to update tests I feel like the user-friendliness of the enhancements makes adding another function to PHP worth it. (e.g. copying short_var_export() into a code snippet such as the expectation for a unit test or a configuration) I don't believe I've seen an RFC for a separate function before. Also, a native C implementation would be much more efficient than a polyfill implemented in PHP, e.g. https://github.com/brick/varexporter/issues/14 I plan to start an RFC document shortly. Thoughts? (e.g. for the name, short_var_export() seemed more appropriate than var_export_short(), pretty_var_export() or canonical_var_export()) Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
