Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110488
To: internals@lists.php.net
References: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
 <EE81C9D2-84ED-4C6E-8A84-F7E5E5282507@gmail.com>
 <d0d696f9-3934-7157-b9b0-1dedebd8d248@gmail.com>
Message-ID: <3bb65fdf-08a6-4d68-3b6b-55fa4ca5f12e@gmail.com>
Date: Thu, 11 Jun 2020 21:24:16 +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: <d0d696f9-3934-7157-b9b0-1dedebd8d248@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 22:38, Rowan Tommins wrote:
> rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure 
> the user never needs to see it.


I'd like to clarify this slightly: I should have said "beyond renaming 
... we should ensure" - I have no particular objection to changing the 
handful of places outside of parse errors that T_PAAMAYIM_NEKUDOTAYIM 
might appear.


> 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 '::' 


To ensure I'm not making unreasonable demands of others, I had a go at 
implementing this change, resulting in this straight-forward patch: 
https://github.com/php/php-src/compare/master...IMSoP:parse-error-poc?diff=split

I believe there's code in zend_yytnamerr that could be tidied up if we 
never want these token names, but also scope for other improvements in 
the output - for instance, we might want to say "unexpected quoted 
string 'foo'" instead of just "unexpected 'foo'".

There's also at least dozens of tests that will need to be changed to 
account for the new messages.


However, it's enough to demonstrate the difference such a change would make:


Input
::::::::::::::::
Before
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM), 
expecting end of file
After
Parse error: syntax error, unexpected '::', expecting end of file

Input
$$$$$$$$$
Before
Parse error: syntax error, unexpected end of file, expecting variable 
(T_VARIABLE) or '{' or '$'
After
Parse error: syntax error, unexpected end of file, expecting variable or 
'{' or '$'

Input
"foo" "bar"
Before
Parse error: syntax error, unexpected '"bar"' (T_CONSTANT_ENCAPSED_STRING)
After
Parse error: syntax error, unexpected '"bar"'


I think all of the above examples are easier to understand after than 
before.

I would be interested to hear reasons not to pursue this idea further.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]