Re: [RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
| From: | Rowan Tommins | 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_NEKUDOTAYIMSince 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]