var_export - use short array syntax for readability #2699
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
As can be seen from the number of tests this PR has caused to fail, this constitutes a BC break, and one that will (rather unnecessarily) cause a number of test suites to fail elsewhere too. This change also introduces an inconsistency between |
|
you might be right; I updated all test I could find but looking at the CI output there are a lot more tests that depend on this behavior. |
|
This one has come up a few times already and the conclusion is basically always as @tpunt said. It's a cosmetic change, but one that is going to cause test failures. #1776 is another variant that added an option instead, but was also rejected. #2422 tried to change NULL casing, same thing. As such, I'm closing this PR. |
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Jan 18, 2021
Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. (Changing var_export would result in thousands of failures in php-src alone) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from 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 add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as `"['item1'"]` rather than `"array(\n 0 => 'item1',\n)"` 4. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 5. Support `SHORT_VAR_EXPORT_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. `SHORT_VAR_EXPORT_NO_WHITESPACE` may be added in the future. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. 2. This saves a few bytes if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output: ```php \ArrayObject::__set_state([ 'a', [ 'b', ], ]) oneline: \ArrayObject::__set_state(['a', ['b']]) ```
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Jan 18, 2021
Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. (Changing var_export would result in thousands of failures in php-src alone) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from 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 add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as `"['item1']"` rather than `"array(\n 0 => 'item1',\n)"` 4. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 5. Support `SHORT_VAR_EXPORT_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. `SHORT_VAR_EXPORT_NO_WHITESPACE` may be added in the future. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. (or to dump values to see in utilities) 2. This saves a few bytes if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output: ```php \ArrayObject::__set_state([ 'a', [ 'b', ], ]) oneline: \ArrayObject::__set_state(['a', ['b']]) ```
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Jan 21, 2021
Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. (Changing var_export would result in thousands of failures in php-src alone) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from 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 add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as `"['item1']"` rather than `"array(\n 0 => 'item1',\n)"` Always render empty lists on a single line 4. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 5. Support `SHORT_VAR_EXPORT_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. `SHORT_VAR_EXPORT_NO_WHITESPACE` may be added in the future. 6. Escape control characters("\x00"-"\x1f") inside of double quoted strings instead of single quoted strings mixed with ` . "\0" . `. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. (or to dump values to see in utilities) 2. This saves a few bytes if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output: ```php \ArrayObject::__set_state([ 'a', [ "x\r\ny", ], [], ]) oneline: \ArrayObject::__set_state(['a', ["x\r\ny"], []]) ``` WIP work on exporting "" wip
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Jan 22, 2021
Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. (Changing var_export would result in thousands of failures in php-src alone) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from 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 add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as `"['item1']"` rather than `"array(\n 0 => 'item1',\n)"` Always render empty lists on a single line 4. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 5. Support `SHORT_VAR_EXPORT_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. `SHORT_VAR_EXPORT_NO_WHITESPACE` may be added in the future. 6. Escape control characters("\x00"-"\x1f") inside of double quoted strings instead of single quoted strings mixed with ` . "\0" . `. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. (or to dump values to see in utilities) 2. This saves a few bytes if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output: ```php \ArrayObject::__set_state([ 'a', [ "x\r\ny", ], [], ]) oneline: \ArrayObject::__set_state(['a', ["x\r\ny"], []]) ``` WIP work on exporting "" wip
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Feb 5, 2021
Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. (Changing var_export would result in thousands of failures in php-src alone) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from 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 add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 3. Render lists as `"['item1']"` rather than `"array(\n 0 => 'item1',\n)"` Always render empty lists on a single line 4. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 5. Support `SHORT_VAR_EXPORT_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. `SHORT_VAR_EXPORT_NO_WHITESPACE` may be added in the future. 6. Escape control characters("\x00"-"\x1f") inside of double quoted strings instead of single quoted strings mixed with ` . "\0" . `. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. (or to dump values to see in utilities) 2. This saves a few bytes if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output: ```php \ArrayObject::__set_state([ 'a', [ "x\r\ny", ], [], ]) oneline: \ArrayObject::__set_state(['a', ["x\r\ny"], []]) ``` WIP work on exporting "" wip
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Feb 5, 2021
…tive for var_export RFC: https://wiki.php.net/rfc/readable_var_representation Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code (php-src tests, PECL tests, and applications written in PHP) is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. ~~(Changing var_export would result in thousands of failures in php-src alone)~~ (haven't counted yet) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from var_export: 1. var_representation() unconditionally returns a string 2. Use `null` instead of `NULL` - the former is recommended by more coding guidelines (https://www.php-fig.org/psr/psr-2/). 3. Change the way indentation is done for arrays/objects. See ext/standard/tests/general_functions/short_var_export1.phpt (e.g. always add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 4. Render lists as `"['item1']"` rather than `"array(\n 0 => 'item1',\n)"` Always render empty lists on a single line, render multiline by default when there are 1 or more elements 5. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 6. Support `VAR_REPRESENTATION_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. 7. Escape control characters("\x00"-"\x1f" and "\x7f"(backspace)) inside of double quoted strings instead of single quoted strings with unescaped control characters mixed with ` . "\0" . `. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. (or to dump values to see in utilities) 2. This often saves a few bytes (except for some binary strings) if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output (see ext/standard/tests/general_functions/var_representation1.phpt for more examples): ```php \ArrayObject::__set_state([ 'a', [ "x\r\ny", ], [], ]) oneline: \ArrayObject::__set_state(['a', ["x\r\ny"], []]) ``` Double quoted strings are used if the string contains \x00-\x1f or \x7f (control characters including `\r`, `\n`, `\t`, and backspace) The ascii range 0x00-0x7f is encoded as follows if double quoted strings are used (`\r`, `\n`, `\t`, `\$`, `\\`, `\"`, in addition to other control characters and backspace encoded as hex escaped characters) ```php // 0x00-0x1f "\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f" // 0x20-0x7f " !\"#\$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f" ```
TysonAndre
added a commit
to TysonAndre/php-src
that referenced
this pull request
Feb 6, 2021
…tive for var_export RFC: https://wiki.php.net/rfc/readable_var_representation Prior RFCs have proposed adding to the option list of var_export and been rejected or had development stop: - A lot of code (php-src tests, PECL tests, and applications written in PHP) is already using var_export, and may be relying on the old behaviors for unit tests (asserting exact representation), etc. ~~(Changing var_export would result in thousands of failures in php-src alone)~~ (haven't counted yet) - Code compatibility with PHP 5 has also been brought up as a reason to keep var_export output the same. - See phpGH-2699 and linked PRs. - Extending `var_export` by adding a third argument is impossible to polyfill in older php versions, and would result in a ArgumentCountError in php 8.0 - See https://externals.io/message/109415 This has the following differences from var_export: 1. var_representation() unconditionally returns a string 2. Use `null` instead of `NULL` - the former is recommended by more coding guidelines (https://www.php-fig.org/psr/psr-2/). 3. Change the way indentation is done for arrays/objects. See ext/standard/tests/general_functions/short_var_export1.phpt (e.g. always add 2 spaces, never 3 in objects, and put the array start on the same line as the key) 4. Render lists as `"['item1']"` rather than `"array(\n 0 => 'item1',\n)"` Always render empty lists on a single line, render multiline by default when there are 1 or more elements 5. Prepend `\` to class names so that generated code snippets can be used in namespaces without any issues. 6. Support `VAR_REPRESENTATION_SINGLE_LINE` in $flags. This will use a single-line representation for arrays/objects, though strings with embedded newlines will still cause newlines in the output. 7. Escape control characters("\x00"-"\x1f" and "\x7f"(backspace)) inside of double quoted strings instead of single quoted strings with unescaped control characters mixed with ` . "\0" . `. Having this available in php-src is useful for the following reasons: 1. It's convenient to be able to dump a snippet and use that in your source code with less reformatting, updating namespaces, etc. (or to dump values to see in utilities) 2. This often saves a few bytes (except for some binary strings) if the output of var_export() for an object/array is saved to disk, used as an array key, etc. 3. This is possibly more readable for list-like arrays 4. This can start being used in short, self-contained scripts if available. 5. The checks for infinite recursion are possible to polyfill with ReflectionReference or other approaches, but error prone to implement from scratch. Example short_var_export output (see ext/standard/tests/general_functions/var_representation1.phpt for more examples): ```php \ArrayObject::__set_state([ 'a', [ "x\r\ny", ], [], ]) oneline: \ArrayObject::__set_state(['a', ["x\r\ny"], []]) ``` Double quoted strings are used if the string contains \x00-\x1f or \x7f (control characters including `\r`, `\n`, `\t`, and backspace) The ascii range 0x00-0x7f is encoded as follows if double quoted strings are used (`\r`, `\n`, `\t`, `\$`, `\\`, `\"`, in addition to other control characters and backspace encoded as hex escaped characters) ```php // 0x00-0x1f "\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f" // 0x20-0x7f " !\"#\$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f" ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For readability it would be nice if var_export uses the new short syntax for arrays, instead of the more verbose old variant. This PR fixes that and all testcases that check it