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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php