Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110473
To: internals@lists.php.net
References: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
 <EE81C9D2-84ED-4C6E-8A84-F7E5E5282507@gmail.com>
Message-ID: <d0d696f9-3934-7157-b9b0-1dedebd8d248@gmail.com>
Date: Wed, 10 Jun 2020 22:38:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <EE81C9D2-84ED-4C6E-8A84-F7E5E5282507@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
From: rowan.collins@gmail.com (Rowan Tommins)

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]