RFC: var_export - short syntax for array

php.internals

Влад Макин

7 years ago
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

Sara Golemon

7 years ago
On Tue, Aug 20, 2019 at 1:05 PM Влад Макин <vamakin@gmail.com> wrote:
> 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

Влад Макин

7 years ago
Thanks for the feedback! I will back with improved version of RFC. вт, 20 авг. 2019 г., 23:01 Sara Golemon <pollita@php.net>:

Andreas Hennings

7 years ago
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:

Lynn

7 years ago
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

Benjamin Morel

7 years ago
> > 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