Re: [RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

From: Date: Wed, 10 Jun 2020 21:38:13 +0000
Subject: Re: [RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-110473@lists.php.net to get a copy of this message
On 10/06/2020 19:28, Claude Pache wrote:
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.
I think this is a really good point, and I would like to expand on it: rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure the user never needs to see it. A long time ago, PHP's parser errors were extremely cryptic, e.g. "::::::::::" would tell you:
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
Since PHP 5.4 (according to https://3v4l.org/Hdjk8) the error message includes the actual token encountered:
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM)
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 '::'
Imagine you are a new PHP developer, who has only the vaguest idea of what "parse" means; along with '::' (T_PAAMAYIM_NEKUDOTAYIM) you may encounter such mysteries as these: '<<' (T_SL) '>>' (T_SR) __NAMESPACE__ (T_NS_C) ''foo'' (T_CONSTANT_ENCAPSED_STRING) [which is a string, not a constant] 'foo' (T_STRING) [which is definitely not a string, but might be a constant] ... (T_ELLIPSIS) [a lot of people will misread this as "ellipse", a much more common word] ** (T_POW) [is that the Star Trek character, or the rock band named after her?] Even straight-forward names like '==' (T_IS_EQUAL) are confusing - for years I wondered what that "T_" meant, my experience with Delphi making me guess at "type", which didn't make much sense. I can see a small advantage of including something that is easy to search for; but how often does the solution to a parse error depend on exactly what the unexpected token was, so that searching for "Parse error: syntax error, unexpected" wouldn't give enough of a hint? Other information currently missing from the message - e.g. column number, hints about unclosed blocks - is likely to be far more useful. Regards, -- Rowan Tommins (né Collins) [IMSoP]

« previous php.internals (#110473) next »