Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106684
MIME-Version: 1.0
References: <CADrJwbmcj_vpb3_diQpP6eJ-Q2pBMf4wOv4eUf=iqjAWK2WbAg@mail.gmail.com>
 <CAESVnVqKoytrO3epvAC2pVK5XrevteO4zjFto98aBsD3rD-_Mg@mail.gmail.com> <CADrJwb=rfRt=wKvW9eB3xjHvHuadQTpW_99=7Ec8LhOGCeoKyA@mail.gmail.com>
In-Reply-To: <CADrJwb=rfRt=wKvW9eB3xjHvHuadQTpW_99=7Ec8LhOGCeoKyA@mail.gmail.com>
Date: Wed, 21 Aug 2019 10:25:18 +0200
Message-ID: <CAH0Uv3GH6S=AQEj56oL7y4kYuVX_qQ4Ks7BsZ6+LXTGosKHgYA@mail.gmail.com>
To: =?UTF-8?B?0JLQu9Cw0LQg0JzQsNC60LjQvQ==?= <vamakin@gmail.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000edfb2d05909c5086"
Subject: Re: [PHP-DEV] RFC: var_export - short syntax for array
From: andreas@dqxtech.net (Andreas Hennings)

--000000000000edfb2d05909c5086
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

=D0=92=D0=BB=D0=B0=D0=B4 =D0=9C=D0=B0=D0=BA=D0=B8=D0=BD <vamakin@gmail.com>=
 schrieb am Mi., 21. Aug. 2019, 08:55:

> Thanks for the feedback!  I will back with improved version of RFC.
>
> =D0=B2=D1=82, 20 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3., 23:01 Sara Golemon <po=
llita@php.net>:
>
> > On Tue, Aug 20, 2019 at 1:05 PM =D0=92=D0=BB=D0=B0=D0=B4 =D0=9C=D0=B0=
=D0=BA=D0=B8=D0=BD <vamakin@gmail.com> wrote:
> >
> >> I would like to propose a little change in var_export function behavio=
r.
> >> For today, this function returns string representation of array in old
> >> style with =E2=80=9Carray=E2=80=9D keyword:
> >>
> >> var_export([]); // array()
> >>
> >> I think it would be better if the function returned array representati=
on
> >> in
> >> modern square brackets syntax:
> >>
> >> var_export([]); // []
> >>
> >> I do like the idea of doing this, and would even be generally okay wit=
h
> > just making always work that way since the introduction of square brack=
et
> > syntax is really *quite* old.
> >
> > The only people I could see being bothered by the change in output woul=
d
> > 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 10=
k
> > 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 t=
o
> > 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 =3D false, int $options =
=3D 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
> >
>

--000000000000edfb2d05909c5086--