Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110753
MIME-Version: 1.0
References: <CAFPFaMLAt_p52-ZWL5VAJENgQ-KznYHPidLaC3HaU3n338thTw@mail.gmail.com>
 <php.internals-110738@news.php.net> <5ef7505d.1c69fb81.a3d3d.67e7SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5ef7505d.1c69fb81.a3d3d.67e7SMTPIN_ADDED_MISSING@mx.google.com>
Date: Sun, 28 Jun 2020 00:53:35 +0200
Message-ID: <CAFPFaMLEeRkY1UtO1qaS5F5tVn_BP8qYQ5LDcb9TtSNiYdYMeg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bb299c05a918b248"
Subject: Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
From: george.banyard@gmail.com ("G. P. B.")

--000000000000bb299c05a918b248
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Andrea, Benjamin, and others,

Better error messages are obviously better than just replacing the name of
the token, however this argument is saying that because this isn't perfect
let's do nothing.

I wasn't aware that Rowan had made good progress on his patch, however, if
this patch needs an RFC, which it might not, there is still no guarantee on
having better error messages for PHP 8.0.

Now, this may just me, but I find the argument that "::" is present
relatively weak as when I scan a PHP parse error, the first thing I look
for is the token name as there are only 3 parse errors which have the added
information of what the token represents, namely T_SL, T_SR, and
T_PAAMAYIM_NEKUDOTAYIM. T_SL and T_SR also have this issue but I would
expect beginners to not hit this as often as I don't expect them to do
anything with bit shifts, and the only other way that they may encounter it
is by doing a bad git merge.

I find it highly frustrating, and borderline offensive, that we are being
asked to go from a simple, non BC breaking, easy to enact change, to a
semi-major overhaul of how error messages should look like. I personally
have no interest in learning Bison and how to implement that as a separate
improvement to PHP. I'm just glad that Rowan decided to take on this
challenge.

Even if better error messages come about, some people will still need to
deal with the token, such as static analyser, code sniffers, code style
tools, etc. Obviously people working on these tools aren't beginners and
deal with the weird token name just fine, or use the T_DOUBLE_COLON alias
if they can. But why should it still be like this? This change has no BC
break, makes English the consistent language for token names. Moreover,
something being historic doesn't mean it shouldn't be touched.

My perception is that most of the community finds it baffling why anyone
would be against this change.

On Sat, 27 Jun 2020 at 15:57, Andrea Faulds <ajf@ajf.me> wrote:

> As for parser errors, I don't know how easy they would be to improve=E2=
=80=A6 is
> it even possible for us to do so without using a hand-written parser
> instead of an auto-generated one? (I have no idea.)

This may be done using Bison 3.6, which got released in May of this year,
as seen by this PR: https://github.com/php/php-src/pull/5416 However, I
don't expect us to be able to use this as Bison 3.6, won't be present on
most distrib until a couple of years.

Best regards
George P. Banyard

--000000000000bb299c05a918b248--