Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110498
MIME-Version: 1.0
References: <CAFPFaMLZJV1BO_GdE7h73DVFaN7LiejeL1RJHL7QEoSa5B1H=A@mail.gmail.com>
 <EE81C9D2-84ED-4C6E-8A84-F7E5E5282507@gmail.com> <CAHWSxWSznXXtx_Duv0tJrU+sp-ytgPPZvxmat6ODwnr-FBjZJQ@mail.gmail.com>
 <CAESVnVq9HbEexZmbzPZZXU3nvTQiyJqtjdM9dO7wnO29G=xtvg@mail.gmail.com> <CAJmjfvUiO8HOB_HFohEV40o-RYd5iBYVw=MtdM+r4W1Gz7MbLQ@mail.gmail.com>
In-Reply-To: <CAJmjfvUiO8HOB_HFohEV40o-RYd5iBYVw=MtdM+r4W1Gz7MbLQ@mail.gmail.com>
Date: Fri, 12 Jun 2020 11:52:45 +0100
Message-ID: <CALKiJKqHL3t+hh+WGLZYsm0z-qff07WzJR_BO6SC1Tq82apcuA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000520f4c05a7e0e18c"
Subject: Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000520f4c05a7e0e18c
Content-Type: text/plain; charset="UTF-8"

On Fri, 12 Jun 2020 at 10:30, Jakob Givoni <jakob@givoni.dk> wrote:

> > Token names shouldn't show up.  Everyone is agreeing with that statement.
> > Universally.  Let's fix that problem rather than create new ones by not
> > addressing the underlying issue.
>
> Are you saying that this RFC is creating a new problem? If so, please
> elaborate.
>


There is a small nuisance for anyone relying on the exact output of the
parser messages, and a small chance of further confusion from existing
users ("what's T_DOUBLE_COLON, I've never seen that before"). To emphasise:
these are very small nuisances, and not a reason to decline the renaming.

If we're going to change the errors anyway, we might as well hide the token
names at the same time, for barely more impact. If I don't see any
objection, I will tidy up my patch to do so this weekend.

If that change is made in 8.0, renaming the token is, as you say, almost
entirely internal.



On Fri, 12 Jun 2020 at 11:04, Guilliam Xavier <guilliam.xavier@gmail.com>
wrote:

> Could this be discussed rather in the "Improvement to errors" thread?
https://externals.io/message/110276

I will post a new thread to discuss details when I've learned more about
what's actually possible with the current parser.

I may be wrong, but I believe the examples given in that message would
require a completely separate implementation, because they are raised at
run-time by the ZPP macros, whereas the ones discussed in this thread are
raised directly by the parser.

In both cases, I think we know roughly what we'd like to see, so there's
not much else to say until somebody looks into actually doing it.


Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000520f4c05a7e0e18c--