June 27, 2020 10:20 (Benjamin Eberlei)
On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds <> wrote:

> Hi, > > G. P. B. wrote: > > > > 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.) >
This is the same reason that I voted no. 1. The token name has historic value and should be preserved as such 2. as several people suggested in the original RFC discussion, we should just not display tokens in error messages anymore. That should have been the RFCs solution, not renaming the token
> > Thanks, > Andrea > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: > >
June 27, 2020 19:40 (Dan Ackroyd)
On Sat, 27 Jun 2020 at 11:20, Benjamin Eberlei <> wrote:

> 1. The token name has historic value and should be preserved as such
I don't think it has historic value. It might have nostalgic value but nostalgia for:
> I think everyone hits it once or twice, has the "wtf?" moment, googles, and > never forgets it again - even if they can't pronounce it...
is not a great piece of nostalgia. But regardless of the past value, it's the current and future trade-offs we should be considering. i.e. is the cost of changing it bigger or smaller than the benefit of not having a token name that can only be reasoned about after googling. I haven't seen anyone say any cost for changing it. Even if the work is done to improve the error messages, avoiding having a token that you can't grok the meaning from the name of it, is a small improvement. So the tradeoff appears to be very small or zero cost, versus a benefit for everyone who hasn't already stumbled into it as a blocker for their understanding of internals. cheers Dan Ack