Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110738
To: internals@lists.php.net
References: <CAFPFaMLAt_p52-ZWL5VAJENgQ-KznYHPidLaC3HaU3n338thTw@mail.gmail.com>
Date: Sat, 27 Jun 2020 11:56:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
MIME-Version: 1.0
In-Reply-To: <CAFPFaMLAt_p52-ZWL5VAJENgQ-KznYHPidLaC3HaU3n338thTw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to
 T_DOUBLE_COLON
From: ajf@ajf.me (Andrea Faulds)
Message-ID: <php.internals-110738@news.php.net>

Hi,

G. P. B. wrote:
> https://wiki.php.net/rfc/rename-double-colon-token

I have voted No to this, and I hope I can convince some others to do the 
same.

T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably 
nobody in internals who doesn't know what it means, and for new 
contributors, it is easy to find the definition, and note that it is 
hardly the only token name that they will need to look up. It is also a 
fun nod to the history of PHP, and I think it would be a shame to lose 
that.

I mention the internals usage first and foremost, because it should be 
remembered that token names are merely an implementation detail of the 
PHP interpreter, unless you're using token_get_all (which by the way 
already has the alias T_DOUBLE_COLON). In other words, it's not 
something the vast majority of userland developers should ever encounter 
or have to think about.

Of course, if T_PAAMAYIM_NEKUDOTAYIM was never encountered by userland 
developers, this RFC wouldn't exist. The thing is, I don't think 
T_DOUBLE_COLON should be encountered by userland developers either — in 
my view, as an implementation detail, token names shouldn't be part of 
parser error messages at all. If we were to remove token names from the 
parser errors, we would avoid the problem this RFC seeks to solve. For 
most tokens we could simply display the characters it corresponds to 
(e.g. "::" for T_PAAMAYIM_NEKUDOTAYIM, which we already do!), and for 
those with variable content (e.g. T_STRING) we could display a 
human-readable description of what is expected (e.g. "an identifier").

I think the case for not renaming T_PAAMAYIM_NEKUDOTAYIM, and instead 
improving the error messages, is stronger when you consider that is not 
the only token with a name that might confuse people outside internals. 
For example, T_STRING is a very common token, but the name is probably 
going to surprise most userland developers who encounter it in an error 
message, because it doesn't mean a literal string. Even for tokens with 
more conventional names, it is unnecessary extra information. I think 
renaming just T_PAAMAYIM_NEKUDOTAYIM is not a full solution to the 
problem this RFC intends to solve.

Apropos of that:

 > We did acknowledge the suggestion of dropping the token name from the
 > error message directly, but in our opinion this is an orthogonal
 > change to the one proposed, and has the risk of not landing in PHP
 > 8.0.

Is PHP 8.0 an all-important? If we _don't_ rename the tokens, but simply 
improve the error message, that might be allowable in a patch release 
(e.g. 8.0.1).

(I also don't think we should rush things if we are unsure about them, 
given the consequences that has had in the past.)

Thanks,
Andrea