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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
