Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109569
MIME-Version: 1.0
References: <CAL+t6cFeiGzLbfaQB0o2JKSx1OdfYYbY+k6QTG0V3H344XbCEA@mail.gmail.com>
 <CAG9XoMTHn6-Cu47w5PdFb4oYFtRYQahB72ZgNxVsEYWdjyTv8g@mail.gmail.com>
 <CAESVnVoCLJUosHkvbd7xV-a+4CDB7CpCMp+Az=dhVCAqS_63mw@mail.gmail.com>
 <CAG9XoMTfB0W+3g_1FiGnBvKsVi8++N9adpAodAw-9NDyjSs4LA@mail.gmail.com>
 <CAESVnVrPWQ119DV5j_zQAsA_6s3AwEQu=jfasBavOD1vs+mC0w@mail.gmail.com>
 <CAG9XoMRtiOTijwtg-RviUCdszhEoB7WUPSzWNRsTgrFkvrHwwg@mail.gmail.com>
 <CAESVnVpXQO6hhjHFa6gwyfXi-_N4mEwYCCiDGf-5b7X1YUdtYg@mail.gmail.com>
 <CAPKYkKy68bGCWuChqFBw0zRnaDF8c=Wmv-c8UVyd5B5jkGdHTA@mail.gmail.com>
 <CAESVnVqFiVLYF4HapY4qxpXhJrJyexeK1t7dBmZ4cFzuNHHeBQ@mail.gmail.com>
 <5e87a7aa.1c69fb81.2e0a2.74daSMTPIN_ADDED_MISSING@mx.google.com>
 <CAL+t6cEBm_3nhceX6yuNQDYyOfZd6KZky54C_qAzZjiyvxnyQQ@mail.gmail.com> <CAL+t6cFp7TrH4YU=9zFQCyA+qKSRNUjg9TnQf4i3GSTVDNCJ9g@mail.gmail.com>
In-Reply-To: <CAL+t6cFp7TrH4YU=9zFQCyA+qKSRNUjg9TnQf4i3GSTVDNCJ9g@mail.gmail.com>
Date: Wed, 8 Apr 2020 15:46:44 +0200
Message-ID: <CAC5V6gigm6rdcTpMSWrhwFT7_E5sbENcfwvHq4YCFENPx2nCPg@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax
 touse short hand arrays
From: guilliam.xavier@gmail.com (Guilliam Xavier)

On Wed, Apr 8, 2020 at 3:12 PM Sherif Ramadan <theanomaly.is@gmail.com> wrote:
>
> So to recap on what's been discussed so far, because I plan to bring this
> to a vote next week...
>
> I am updating the RFC to reflect that the change will no longer break
> backwards compatibility. I will be adding an flags argument with the
> following 3 optional bitwise flags for var_export:
>
> - VAR_EXPORT_SHORT_ARRAY [Triggers short-array syntax]
> - VAR_EXPORT_NO_INDEX [Discards numbered indexes in arrays (only if they
> are sequential from 0)]
> - VAR_EXPORT_NO_WHITESPACE [For one-liners]
>
> This complicates the implementation slightly, but I think it brings a
> greater net-benefit.

Hello,

First, thank you for proposing this RFC. I have no strong opinion
either way, but anyway it cannot work as is, because var_export
already has a second optional parameter (bool $return = false). You
could add the flags as a third optional parameter (int $options = 0),
or maybe make it replace (extend) the existing one and add an extra
constant, say VAR_EXPORT_RETURN = 1, so that it can be combined
(although I'm not sure that changing the type from bool to int (or
maybe bool|int) would be BC-compliant...)

Moreover the RFC currently says that var_export([1, 2, 3]) produces
```
array(1, 2, 3)
```
but it actually produces
```
array (
  0 => 1,
  1 => 2,
  2 => 3,
)
```

Regards,

-- 
Guilliam Xavier