Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109468
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>
In-Reply-To: <CAPKYkKy68bGCWuChqFBw0zRnaDF8c=Wmv-c8UVyd5B5jkGdHTA@mail.gmail.com>
Date: Mon, 30 Mar 2020 12:42:44 -0500
Message-ID: <CAESVnVqFiVLYF4HapY4qxpXhJrJyexeK1t7dBmZ4cFzuNHHeBQ@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, Sherif Ramadan <theanomaly.is@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000029da7b05a215fb3d"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to
 use short hand arrays
From: pollita@php.net (Sara Golemon)

--00000000000029da7b05a215fb3d
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> Just out of curiosity, is there any reason we couldn't add an optional
> parameter called "$short_array" or whatever that defaults to false? Then
> there shouldn't be any backwards compatibility issues.
>
> None at all, though I'd make it an `int $options = 0` similar to
json_encode().  I'd have a FAR easier time supporting that than a wholesale
BC break for the sake of breaking BC.

I can think of a few options:
  VAR_EXPORT_SHORT_ARRAY => use [] instead of arrray()
  VAR_EXPORT_NO_WHITESPACE => Keep it concise, single line
  VAR_EXPORT_NO_VECTOR_INDEX => If an array is vector-like, skip indexes
  VAR_EXPORT_UTF8_UESCAPE => Detect places where we can use \u{1234} syntax
for UTF8 strings

Though I'm going to stay with my stated position that I would MUCH rather
this stuff live in userspace.  Just because PHP's penchant for
including the kitchen sink is broken already doesn't mean we should break
it more.

-Sara

-Sara

--00000000000029da7b05a215fb3d--