Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110742
To: internals@lists.php.net
References: <CAFPFaMLAt_p52-ZWL5VAJENgQ-KznYHPidLaC3HaU3n338thTw@mail.gmail.com>
 <php.internals-110738@news.php.net>
Date: Sat, 27 Jun 2020 15:57:44 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <php.internals-110738@news.php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to
 T_DOUBLE_COLON
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-110742@news.php.net>

Hi again,

A further and perhaps more important thought: I think the token names 
are actually the least confusing part of parser errors, even for the 
famous T_PAAMAYIM_NEKUDOTAYIM. Changing it to T_DOUBLE_COLON may not 
help much, because the parser only tells you what the next token it 
expected was, not *why* it expected it, i.e. what is wrong with the 
syntax. A user might think they need to add a :: but it's not their 
actual problem.

For example, if you google for “T_PAAMAYIM_NEKUDOTAYIM” errors, one of 
the classic examples where you got such an error was:

   var_dump(empty(TRUE));

If the error had said T_DOUBLE_COLON it would still be mystifying: why 
did PHP think you needed a :: there? And just adding one won't fix the 
problem! The actual issue was that empty() used to not support arbitrary 
expressions, only variables, and the expected T_PAAMAYIM_NEKUDOTAYIM is 
because the only way TRUE could be part of a variable would be if it was 
a class name (TRUE::$foo). The way to fix it is to replace empty() with 
the ! operator, but you'd have a hard time figuring that out from the 
error. I think this is the real reason T_PAAMAYIM_NEKUDOTAYIM was 
famous: even if you knew it meant double colon, the error message is 
still cryptic.

The good news is T_PAAMAYIM_NEKUDOTAYIM is no longer quite the menace it 
once was. PHP 7's parser and syntax overhaul (thank you Nikita!) fixed 
it in some places:

   $ php -r 'var_dump(isset(TRUE));'
   Fatal error: Cannot use isset() on the result of an expression (you 
can use "null !== expression" instead)

And other places where you might have once seen T_PAAMAYIM_NEKUDOTAYIM 
now give a different unhelpful parser error, which renaming 
T_PAAMAYIM_NEKUDOTAYIM will not help with:

   $ php -r 'unset(TRUE);'
   Parse error: syntax error, unexpected ')', expecting '[' in Command 
line code on line 1

So if there was ever a time to rename T_PAAMAYIM_NEKUDOTAYIM, it would 
have been many years ago. There's much less benefit to renaming it now, 
especially given it says “'::' (T_PAAMAYIM_NEKUDOTAYIM)” if you manage 
to get an error containing it, so you don't even need to google it. The 
specific name a token is given is the least of the problems there.

As for parser errors, I don't know how easy they would be to improve… 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.)

Regards,
Andrea