[RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

(Trying again without a plussed address, which is too much hassle for
the ML. Sorry for dups.)

Honestly, I'd rather PHP didn't barf raw lex tokens to the end user
for its output. But until then, renaming it seems wise.

Didn't someone come out and claim that the current token is misspelled
Hebrew anyway?

--c

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’t ask for the other parse errors even half as often as 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’s an easter egg joke that refers to the creators of PHP. But that
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’re annoying thousands of people." -Alexander Schrijver

"It’s the same argument everyone else is giving, and really it all 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’t 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 on
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’re 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’ve learned with time
that when I get such an error, it means that I’ve 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’t matter how the offending token is named if
you
know where it is.

—Claude

--

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.

--
Chase Peeler
chasepeeler@gmail.com

On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch ryan.jentzsch@gmail.com
wrote:

OMG the trolling continues even today with this nonsense. Disappointing.

Oh yes. And histrionics will certainly deescalate that issue.

"...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

You know what shows up unambiguously in a google search? "Paamayim
Nekudotayim".
You know what ISN'T unambiguous in a google search? "Double Colon"
You know who don't have an excuse to say "Google is hard"? Software
engineers.

...Two things are broken: Either the token is named badly, or the token
names shouldn’t show up in error messages at all and be replaced with
something a bit more friendly.

Token names shouldn't show up. Everyone is agreeing with that statement.
Universally. Let's fix that problem rather than create new ones by not
addressing the underlying issue.

Once again I plead for logic and sanity. At least have the courage to put

it to a vote.

Absolutely. Put it to a vote. I've got my "no" all locked and loaded.

-Sara

rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure
the user never needs to see it.

I'd like to clarify this slightly: I should have said "beyond renaming
... we should ensure" - I have no particular objection to changing the
handful of places outside of parse errors that T_PAAMAYIM_NEKUDOTAYIM
might appear.

If I understand correctly, the current proposal will instead give us
this:

Parse error: syntax error, unexpected '::' (T_DOUBLE_COLON)

But why not simply this:

Parse error: syntax error, unexpected '::'

To ensure I'm not making unreasonable demands of others, I had a go at
implementing this change, resulting in this straight-forward patch:
https://github.com/php/php-src/compare/master...IMSoP:parse-error-poc?diff=split

I believe there's code in zend_yytnamerr that could be tidied up if we
never want these token names, but also scope for other improvements in
the output - for instance, we might want to say "unexpected quoted
string 'foo'" instead of just "unexpected 'foo'".

There's also at least dozens of tests that will need to be changed to
account for the new messages.

However, it's enough to demonstrate the difference such a change would make:

Input
::::::::::::::::
Before
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM),
expecting end of file
After
Parse error: syntax error, unexpected '::', expecting end of file

Input
$$$$$$$$$
Before
Parse error: syntax error, unexpected end of file, expecting variable
(T_VARIABLE) or '{' or '$'
After
Parse error: syntax error, unexpected end of file, expecting variable or
'{' or '$'

Input
"foo" "bar"
Before
Parse error: syntax error, unexpected '"bar"' (T_CONSTANT_ENCAPSED_STRING)
After
Parse error: syntax error, unexpected '"bar"'

I think all of the above examples are easier to understand after than
before.

I would be interested to hear reasons not to pursue this idea further.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Hi!

a) Character count (at line 456, character 23)

b) Quote either the remainder or the parsed section on the line (MySQL
quotes the remainder, for example)

c) Quote the whole line with an indicator where the error occurred. I'm
not sure what the best way to do this would be - generically this could
be encapsulated in several values: The line content, token start
character count, token length / end character count

I really like the combination of A + C. After using php for 13 years the

If we could do the same as, for example, clang does: just display some
indication where the problem happened within the code, with the line
that caused it. Certainly not displaying internal token names, unless I
am debugging the parser they are useless.

--
Stas Malyshev
smalyshev@gmail.com