Re: RFC: var_export - short syntax for array
| From: | Влад Макин | Date: | Wed, 21 Aug 2019 06:55:15 +0000 |
| Subject: | Re: RFC: var_export - short syntax for array | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-106683@lists.php.net to get a copy of this message | ||
Thanks for the feedback! I will back with improved version of RFC.
вт, 20 авг. 2019 г., 23:01 Sara Golemon <pollita@php.net>:
> 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
>