Hello!
I would like to propose a little change in var_export function behavior.
For today, this function returns string representation of array in old
style with “array” keyword:
var_export([]); // array()
I think it would be better if the function returned array representation in
modern square brackets syntax:
var_export([]); // []
I think now is good time for this change because short syntax is common and
used by almost all linters as well as in examples in code standards like
PSR-2 and PSR-12.
Also this change will make it easier in the future to remove old long
syntax from PHP.
I have already implemented the concept of this feature localy (here is the
diif
https://github.com/php/php-src/compare/master...Zlob:modernize_var_export_function).
As you can see, it does not affect a lot of the code.
This change does not break backward compability, becuse it steel returns
valid PHP array. But if it needed, this behaviour can be managed by an
additional optional function parametr.
Looking forward for your comments and suggestions
Sincerely,
Vladislav Makin
I would like to propose a little change in var_export function behavior.
For today, this function returns string representation of array in old
style with “array” keyword:var_export([]); // array()
I think it would be better if the function returned array representation in
modern square brackets syntax:var_export([]); // []
I do like the idea of doing this, and would even be generally okay with
just making always work that way since the introduction of square bracket
syntax is really quite old.
The only people I could see being bothered by the change in output would be
automated code-generation suddenly seeing a (potentially quite massive)
diff as the bracket style changes. As an example,
https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
line var_export() generated list. I'm actually /not/ bothered by the idea
of having a big point-in-time flip of that structure, though I'd want to
make sure all RMs switch versions at the same time, otherwise it could get
noisy.
Perhaps an option to quell any dissent might be to add a third param
$options to allow controlling this behavior.
function var_export(mixed $data, bool $return = false, int $options = 0):
string {}
And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
whatever you want to call the constants depending on which behavior you'd
make default (and honestly, I think we'd make the existing format default).
-Sara
Thanks for the feedback! I will back with improved version of RFC.
вт, 20 авг. 2019 г., 23:01 Sara Golemon pollita@php.net:
I would like to propose a little change in var_export function behavior.
For today, this function returns string representation of array in old
style with “array” keyword:var_export([]); // array()
I think it would be better if the function returned array representation
in
modern square brackets syntax:var_export([]); // []
I do like the idea of doing this, and would even be generally okay with
just making always work that way since the introduction of square bracket
syntax is really quite old.The only people I could see being bothered by the change in output would
be automated code-generation suddenly seeing a (potentially quite massive)
diff as the bracket style changes. As an example,
https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
linevar_export()generated list. I'm actually /not/ bothered by the idea
of having a big point-in-time flip of that structure, though I'd want to
make sure all RMs switch versions at the same time, otherwise it could get
noisy.Perhaps an option to quell any dissent might be to add a third param
$options to allow controlling this behavior.function var_export(mixed $data, bool $return = false, int $options = 0):
string {}And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
whatever you want to call the constants depending on which behavior you'd
make default (and honestly, I think we'd make the existing format default).-Sara
Avoiding disruption is indeed a concern.
As an example, Drupal 7 features module uses a custom variation of
var_export() to write configuration to code, which is then typically
tracked in git.
I am not sure if changing the native var_export() would have an impact
here, and anyway the module can be updated if necessary, to guarantee
stability of the output.
What I would ask is to limit the frequency of change in this function, or
make it opt-in.
There are other issues with the format besides just the long array syntax.
E.g. opening bracket on same line? Indentation?
https://3v4l.org/MFLgd
Ideally all of this would be "normalized" in one go, based on popular
convention (psr-whichever), or it should be opt-in.
Alternatively there could be a new function or class, leaving var_export()
alone.
Влад Макин vamakin@gmail.com schrieb am Mi., 21. Aug. 2019, 08:55:
Thanks for the feedback! I will back with improved version of RFC.
вт, 20 авг. 2019 г., 23:01 Sara Golemon pollita@php.net:
I would like to propose a little change in var_export function behavior.
For today, this function returns string representation of array in old
style with “array” keyword:var_export([]); // array()
I think it would be better if the function returned array representation
in
modern square brackets syntax:var_export([]); // []
I do like the idea of doing this, and would even be generally okay with
just making always work that way since the introduction of square bracket
syntax is really quite old.The only people I could see being bothered by the change in output would
be automated code-generation suddenly seeing a (potentially quite
massive)
diff as the bracket style changes. As an example,
https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
linevar_export()generated list. I'm actually /not/ bothered by the
idea
of having a big point-in-time flip of that structure, though I'd want to
make sure all RMs switch versions at the same time, otherwise it could
get
noisy.Perhaps an option to quell any dissent might be to add a third param
$options to allow controlling this behavior.function var_export(mixed $data, bool $return = false, int $options = 0):
string {}And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
whatever you want to call the constants depending on which behavior you'd
make default (and honestly, I think we'd make the existing format
default).-Sara
On Wed, Aug 21, 2019 at 10:25 AM Andreas Hennings andreas@dqxtech.net
wrote:
Avoiding disruption is indeed a concern.
As an example, Drupal 7 features module uses a custom variation of
var_export()to write configuration to code, which is then typically
tracked in git.
Hi Andreas,
If the output is being tracked in git, it could follow the same rules as
all other code by using a code formatting fixer such as phpcbf. I don't
think the responsibility here is the output format of var_export, as it's
the developer having control over what's being committed to git. I don't
see this as an issue that PHP should solve.
Regards,
Lynn van der Berg
There are other issues with the format besides just the long array syntax.
E.g. opening bracket on same line? Indentation?
For the record, I have a userland implementation of var_export() that does
all of this:
- (object) array export of stdClass for PHP < 7.3
- short array syntax
- bracket on the same line
- array of scalars on a single line (optional)
- export classes without __set_state()
- export closures
https://github.com/brick/varexporter
I'm currently working on supporting object identity and circular references.
Feedback welcome!
— Benjamin