Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109456
MIME-Version: 1.0
References: <CAL+t6cFeiGzLbfaQB0o2JKSx1OdfYYbY+k6QTG0V3H344XbCEA@mail.gmail.com>
 <CA+kxMuRLdXLsOityDuzgTs_eS0e+uubEydS+6YrRwxpm_rgGnw@mail.gmail.com>
In-Reply-To: <CA+kxMuRLdXLsOityDuzgTs_eS0e+uubEydS+6YrRwxpm_rgGnw@mail.gmail.com>
Date: Mon, 30 Mar 2020 11:54:55 -0400
Message-ID: <CAL+t6cGkpMzTT6qyYgsFpuG0PD=Q82tr+xw3tQvBX26trFwqTA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008e9c0b05a21479bb"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to
 use short hand arrays
From: theanomaly.is@gmail.com (Sherif Ramadan)

--0000000000008e9c0b05a21479bb
Content-Type: text/plain; charset="UTF-8"

@Dan Ackroyd <danack@basereality.com>

> That's an aesthetic choice, which not everyone will agree with.
>

Yes, I freely state that in the RFC. Everyone is free to vote how they like.



>
> "There shouldn't be any backwards incompatible changes"
>
> It apparently breaks 25 tests that compare the output of var_export
> with an expected version. Userland users who have similar tests will
> experience similar breaks.
>
>
A test that compares var_export output is a pretty broken test, in my
opinion. This is similar to a test that would use the value of a constant
to test that the constant works. You're testing PHP code you shouldn't care
if it uses the long form array construct or short form. Just test that it
gives you an array.

With that said, I will update the RFC to make note of these tests and I
will fix them should the RFC be voted in.


> Is there any reason to do this change other than aesthetic choice?
>
>
Just because it is aesthetic is not actually an argument against. Why
wouldn't you want to improve the aesthetics of PHP? Is it only an aesthetic
choice, however? Not entirely. I also state that it is easier to read and
type (saves space) and is more inline with JSON notation which is a lot
more ubiquitous these days. These are all pros. I see no cons in that
change.

--0000000000008e9c0b05a21479bb--