On Fri, 12 Jun 2020 at 10:30, Jakob Givoni 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
> So please, let the parser tell me not only the line of the error, but
also the colum.
> Other information currently missing from the message - e.g. column
> number, hints about unclosed blocks - is likely to be far more useful
>> a) Character count (at line 456, character 23)
> >>
> >> b)
On Thu, Jun 11, 2020 at 12:14 AM Sara Golemon wrote:
>
> You know what shows up unambiguously in a google search? "Paamayim
> Nekudotayim".
> You know what ISN'T unambiguous in a google search? "Double Colon"
Straw man. The point being that you wouldn't have to Google "Double
Colon" because it
Hi!
>> a) Character count (at line 456, character 23)
>>
>> b) Quote either the remainder or the parsed section on the line (MySQL
>> quotes the remainder, for example)
>>
>> c) Quote the whole line with an indicator where the error occurred. I'm
>> not sure what the best way to do this would be
On 10/06/2020 22:38, Rowan Tommins wrote:
rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure
the user never needs to see it.
I'd like to clarify this slightly: I should have said "beyond renaming
... we should ensure" - I have no particular objection to changing the
> On Jun 11, 2020, at 04:09, Zeev Suraski wrote:
>
>
> On 11 Jun 2020, at 12:07, Sebastian Bergmann wrote:
>
> Am 11.06.2020 um 00:13 schrieb Sara Golemon:
> Token names shouldn't show up. Everyone is agreeing with that statement.
> Universally. Let's fix that problem rather than create
On 11 Jun 2020, at 12:07, Sebastian Bergmann wrote:
Am 11.06.2020 um 00:13 schrieb Sara Golemon:
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.
+1
+1
Zeev
Am 11.06.2020 um 00:13 schrieb Sara Golemon:
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.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To
On Thu, Jun 11, 2020 at 10:45 AM AllenJB wrote:
>
> This could be either as:
>
> a) Character count (at line 456, character 23)
>
> b) Quote either the remainder or the parsed section on the line (MySQL
> quotes the remainder, for example)
>
> c) Quote the whole line with an indicator where the
On 10/06/2020 16:13, G. P. B. wrote:
Greetings PHP internals,
Kalle Sommer Nielsen and myself are proposing to rename the
T_PAAMAYIM_NEKUDOTAYIM
token into the already existing T_DOUBLE_COLON alias,
T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON.
The RFC is located here:
On Wed, Jun 10, 2020 at 3:14 PM Sara Golemon wrote:
> On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch
> wrote:
>
> > OMG the trolling continues even today with this nonsense. Disappointing.
> >
>
> Oh yes. And histrionics will certainly deescalate that issue.
>
>
> > "...yes, it is broken, people
On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch
wrote:
> OMG the trolling continues even today with this nonsense. Disappointing.
>
Oh yes. And histrionics will certainly deescalate that issue.
> "...yes, it is broken, people have to Google or ask around for a very
> unclear error message when
On 10/06/2020 19:28, Claude Pache wrote:
One parsing error that I still find dreadful after more than 10 years of PHP
coding, is: unexpected T_CONSTANT_ENCAPSED_STRING. Although
T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time that
when I get such an error, it means
On Wed, Jun 10, 2020 at 4:33 PM Ryan Jentzsch
wrote:
> OMG the trolling continues even today with this nonsense. Disappointing.
> Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why::
> "People don’t ask for the other parse errors even half as often as they as
> for
OMG the trolling continues even today with this nonsense. Disappointing.
Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why::
"People don’t ask for the other parse errors even half as often as they as
for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to
Hi,
I appreciate the effort to reduce frustration in PHP coding.
However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and you’re
done for the rest of your life.
May I suggest an improvement that would be much more useful than renaming
tokens?
One parsing error that I still find
(Trying again without a plussed address, which is too much hassle for
the ML. Sorry for dups.)
Honestly, I'd rather PHP didn't barf raw lex tokens to the end user
for its output. But until then, renaming it seems wise.
Didn't someone come out and claim that the current token is misspelled
Encountering T_PAAMAYIM_NEKUDOTAYIM is a right of passage in the PHP
world. I had to deal with it, so should everyone else. :-P
While it'll be bittersweet to see it go, I definitely think this would be a
wise update.
On Wed, Jun 10, 2020 at 12:58 PM Ryan Jentzsch
wrote:
> With over 25+ years
With over 25+ years of software development experience it was In 2016 I was
introduced to the world of PHP development.
One day I came across the most unusual of error messages
"T_PAAMAYIM_NEKUDOTAYIM" What the hell is this?!?
That I needed to waste my time to Google this is simply insane. At the
Greetings PHP internals,
Kalle Sommer Nielsen and myself are proposing to rename the
T_PAAMAYIM_NEKUDOTAYIM
token into the already existing T_DOUBLE_COLON alias,
T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON.
The RFC is located here:
20 matches
Mail list logo
