Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110740
MIME-Version: 1.0
References: <CAFPFaMLAt_p52-ZWL5VAJENgQ-KznYHPidLaC3HaU3n338thTw@mail.gmail.com>
 <5ef71801.1c69fb81.68596.376aSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5ef71801.1c69fb81.68596.376aSMTPIN_ADDED_MISSING@mx.google.com>
Date: Sat, 27 Jun 2020 12:28:54 +0200
Message-ID: <CAF+90c8Z1gRtCxhawuLWkMrfwyNSMFtMO+1Jr+YmoyncW0BvLg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ddb57f05a90e4b5a"
Subject: Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ddb57f05a90e4b5a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds <ajf@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 =E2=80=
=94 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

--000000000000ddb57f05a90e4b5a--