Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110472
MIME-Version: 1.0
References: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
 <EE81C9D2-84ED-4C6E-8A84-F7E5E5282507@gmail.com> <CAHWSxWSznXXtx_Duv0tJrU+sp-ytgPPZvxmat6ODwnr-FBjZJQ@mail.gmail.com>
In-Reply-To: <CAHWSxWSznXXtx_Duv0tJrU+sp-ytgPPZvxmat6ODwnr-FBjZJQ@mail.gmail.com>
Date: Wed, 10 Jun 2020 17:05:58 -0400
Message-ID: <CAPKYkKyL11m6EEpAqc2WMbtGMy3faVh4iLq=LpCFGNbZ=gjRGw@mail.gmail.com>
To: Ryan Jentzsch <ryan.jentzsch@gmail.com>
Cc: Claude Pache <claude.pache@gmail.com>, "G. P. B." <george.banyard@gmail.com>, 
	PHP internals <internals@lists.php.net>, Kalle Sommer Nielsen <kalle@php.net>
Content-Type: multipart/alternative; boundary="0000000000009c5b1c05a7c13627"
Subject: Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000009c5b1c05a7c13627
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 10, 2020 at 4:33 PM Ryan Jentzsch <ryan.jentzsch@gmail.com>
wrote:

> OMG the trolling continues even today with this nonsense. Disappointing.
> Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why=
::
> "People don=E2=80=99t ask for the other parse errors even half as often a=
s they as
> for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to
> them, so it looks unlikely to be a common thing you can Google, nor it
> gives something recognizable to start with [sic] Yes, we all acknowledge
> it=E2=80=99s an easter egg joke that refers to the creators of PHP. But t=
hat
> particular joke has outworn its welcome in the community after repeatedly
> CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine)
>
>
I agree that it isn't the biggest issue in the world. If we had to give up
one of the more impactful changes in order to implement this, it would be a
different story. But that's not the case. There is no trade off here. The
RFC even contains the updates required, so it's not going to take up
anyone's time that could be spent on other features.



> "It's a minor change and an annoyance to a lot of people. Yes, by not
> changing this you=E2=80=99re annoying thousands of people." -Alexander Sc=
hrijver
>
> "It=E2=80=99s the same argument everyone else is giving, and really it al=
l comes
> down to this.:
> Nostalgia is valued over clarity and consistency. Do you guys REALLY want
> to claim that?" -Chad Minick
>
> "...yes, it is broken, people have to Google or ask around for a very
> unclear error message when for the most part errors are (and should be)
> self explanatory
> ...Two things are broken: Either the token is named badly, or the token
> names shouldn=E2=80=99t show up in error messages at all and be replaced =
with
> something a bit more friendly.
> ...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON o=
n
> LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick
>
>
Honestly, I'm not a big fan of the following argument: "However, PHP is for
most people their first programming language and therefore may not have the
instinct to do an online search and will end up frustrated." - Googling is
such a core skill for programming, that if they can't figure that out, they
don't need to be programming.

However, that being said, I don't think that argument is even needed to
justify this RFC anyway.

The only place this MIGHT cause an issue is unit tests that are looking for
that specific string. While I'm not a fan of the "just use find/replace" to
update things argument, I think that's a perfectly valid one here, given
the uniqueness of the string being changed.


> Once again I plead for logic and sanity. At least have the courage to put
> it to a vote.
>
> On Wed, Jun 10, 2020, 12:28 PM Claude Pache <claude.pache@gmail.com>
> wrote:
>
> > 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 renami=
ng
> > tokens?
> >
> > One parsing error that I still find dreadful after more than 10 years o=
f
> > 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 tel=
l
> me
> > where exactly is the error: it tells only the line number, and I have t=
o
> > 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
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

   I have a reputation on this list for being rather conservative about
changes. I'm somewhat sympathetic to the symbolic reasons for keeping it
around. I don't think such reasons outweigh the benefits though. The only
valid solution I would support that didn't rename the token would be if we
removed that token from the error messages altogether. I think that would
be more likely to cause issues, though, since there could be tests that
need SOME sort of token specified.

--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000009c5b1c05a7c13627--