On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds <a...@ajf.me> wrote: > 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 >
Hey Andrea, You convinced me! To vote "yes" on this RFC :P I initially thought that this proposal is simply redundant, because the issue would be fully addressed by a) not displaying token names in errors, which I expect to happen for PHP 8.0, and b) renaming T_PAAMAYIM_NEKUDOTAYIM as far as internal usage is concerned, which is an implementation detail on which internals@ input is not required, but I now realize that there might be friction on point b) without this RFC, so it is better to accept it. Regards, Nikita
