Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110477
To: "G. P. B." <george.banyard@gmail.com>,
 PHP internals <internals@lists.php.net>, Kalle Sommer Nielsen <kalle@php.net>
References: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
Message-ID: <1914c612-99ef-5c12-0409-37424c071220@allenjb.me.uk>
Date: Thu, 11 Jun 2020 09:45:04 +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: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.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: php.lists@allenjb.me.uk (AllenJB)

On 10/06/2020 16:13, G. P. B. wrote:
>   Greetings PHP internals,
>
> Kalle Sommer Nielsen and myself are proposing to rename the
> T_PAAMAYIM_NEKUDOTAYIM
> token into the already existing T_DOUBLE_COLON alias,
> T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON.
>
> The RFC is located here: https://wiki.php.net/rfc/rename-double-colon-token
>
> Although this token is a nod to the valuable contributions made by the
> Isrealie community we believe this token is rather confusing for newcomers.
> Moreso, as PHP is for many people their first programming language,
> they may not have some of the habits like googling errors when
> they are stuck, which leads to a frustrating experience.
>
> As we believe PHP still has many years of existence we think it is time
> to rename this token.
>
> This is backwards compatible with PHP 7 and 5.
> This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM
> and leaves this as a future scope.
>
> As the matter on hand is a relatively straight forward yes/no vote we expect
> it to be held after the minimum 2 week discussion period.
>
> Best regards
>
> George Peter Banyard

Either as an alternative, or as an "as well as" option: I think a better 
way to improve parser error messages would be to include the point in 
the line where the parser error occurred.  This would additionally help 
where a token appears multiple times on the same line.

This could be either as:

a) Character count (at line 456, character 23)

b) Quote either the remainder or the parsed section on the line (MySQL 
quotes the remainder, for example)

c) Quote the whole line with an indicator where the error occurred. I'm 
not sure what the best way to do this would be - generically this could 
be encapsulated in several values: The line content, token start 
character count, token length / end character count

A case where I can see this still not helping is cases where the parse 
error can occur several lines after the actual error (or even at the end 
of the file) due to things like missing  quotes / braces.

AllenJB