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. Влад Макин <vama...@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 <poll...@php.net>: > > > On Tue, Aug 20, 2019 at 1:05 PM Влад Макин <vama...@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 > > >
