Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110469
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
Date: Wed, 10 Jun 2020 20:28:15 +0200
Cc: PHP internals <internals@lists.php.net>,
 Kalle Sommer Nielsen <kalle@php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EE81C9D2-84ED-4C6E-8A84-F7E5E5282507@gmail.com>
References: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Subject: Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
From: claude.pache@gmail.com (Claude Pache)

Hi,

I appreciate the effort to reduce frustration in PHP coding.

However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and =
you=E2=80=99re done for the rest of your life.

May I suggest an improvement that would be much more useful than =
renaming tokens?

One parsing error that I still find dreadful after more than 10 years of =
PHP coding, is:  unexpected T_CONSTANT_ENCAPSED_STRING. Although =
T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I=E2=80=99ve learned =
with time that when I get such an error, it means that I=E2=80=99ve most =
probably omitted or mistyped some punctuation mark somewhere. However, =
PHP is unable to tell me where exactly is the error: it tells only the =
line number, and I have to carefully scan the entirely line to find the =
place. Sometimes, I resort to split the offending line in several ones, =
so that I could get more precise location info.

So please, let the parser tell me not only the line of the error, but =
also the column. Then, it doesn=E2=80=99t matter how the offending token =
is named if you know where it is.

=E2=80=94Claude