Everything

php

[RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

php.internals

Girgias

6 years ago

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: https://wiki.php.net/rfc/rename-double-colon-token

Although this token is a nod to the valuable contributions made by the
Isrealie community we believe this token is rather confusing for newcomers.
Moreso, as PHP is for many people their first programming language,
they may not have some of the habits like googling errors when
they are stuck, which leads to a frustrating experience.

As we believe PHP still has many years of existence we think it is time
to rename this token.

This is backwards compatible with PHP 7 and 5.
This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM
and leaves this as a future scope.

As the matter on hand is a relatively straight forward yes/no vote we expect
it to be held after the minimum 2 week discussion period.

Best regards

George Peter Banyard

Ryan Jentzsch

6 years ago

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 time
I thought to myself that PHP deserved some of the hate. Then I came across
this gem: https://phil.tech/2013/t-paamayim-nekudotayim-v-sanity/
Please for the sake of logic and sanity replace this nonsense with
T_DOUBLE_COLON

On Wed, Jun 10, 2020, 9:14 AM G. P. B. <george.banyard@gmail.com> wrote:

Chase Peeler

6 years ago

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 <ryan.jentzsch@gmail.com>
wrote:

> 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 time
> I thought to myself that PHP deserved some of the hate. Then I came across
> this gem: https://phil.tech/2013/t-paamayim-nekudotayim-v-sanity/
> Please for the sake of logic and sanity replace this nonsense with
> T_DOUBLE_COLON
>
> On Wed, Jun 10, 2020, 9:14 AM G. P. B. <george.banyard@gmail.com> 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:
> > https://wiki.php.net/rfc/rename-double-colon-token
> >
> > Although this token is a nod to the valuable contributions made by the
> > Isrealie community we believe this token is rather confusing for
> newcomers.
> > Moreso, as PHP is for many people their first programming language,
> > they may not have some of the habits like googling errors when
> > they are stuck, which leads to a frustrating experience.
> >
> > As we believe PHP still has many years of existence we think it is time
> > to rename this token.
> >
> > This is backwards compatible with PHP 7 and 5.
> > This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM
> > and leaves this as a future scope.
> >
> > As the matter on hand is a relatively straight forward yes/no vote we
> > expect
> > it to be held after the minimum 2 week discussion period.
> >
> > Best regards
> >
> > George Peter Banyard
> >
>

--
Chase Peeler
chasepeeler@gmail.com

Chuck Adams

6 years ago

(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
Hebrew anyway?

--c

Claude Pache

6 years ago

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 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 that I’ve most probably omitted or mistyped some punctuation mark somewhere. However, PHP is unable to tell me where exactly is the error: it tells only the line number, and I have to carefully scan the entirely line to find the place. Sometimes, I resort to split the offending line in several ones, so that I could get more precise location info.

So please, let the parser tell me not only the line of the error, but also the column. Then, it doesn’t matter how the offending token is named if you know where it is.

—Claude

Ryan Jentzsch

6 years ago

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
them, so it looks unlikely to be a common thing you can Google, nor it
gives something recognizable to start with [sic] Yes, we all acknowledge
it’s an easter egg joke that refers to the creators of PHP. But that
particular joke has outworn its welcome in the community after repeatedly
CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine)

"It's a minor change and an annoyance to a lot of people. Yes, by not
changing this you’re annoying thousands of people." -Alexander Schrijver

"It’s the same argument everyone else is giving, and really it all comes
down to this.:
Nostalgia is valued over clarity and consistency. Do you guys REALLY want
to claim that?" -Chad Minick

"...yes, it is broken, people have to Google or ask around for a very
unclear error message when for the most part errors are (and should be)
self explanatory
...Two things are broken: Either the token is named badly, or the token
names shouldn’t show up in error messages at all and be replaced with
something a bit more friendly.
...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on
LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick

Once again I plead for logic and sanity. At least have the courage to put
it to a vote.

On Wed, Jun 10, 2020, 12:28 PM Claude Pache <claude.pache@gmail.com> wrote:

Chase Peeler

6 years ago

On Wed, Jun 10, 2020 at 4:33 PM Ryan Jentzsch <ryan.jentzsch@gmail.com>
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 T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to
> them, so it looks unlikely to be a common thing you can Google, nor it
> gives something recognizable to start with [sic] Yes, we all acknowledge
> it’s an easter egg joke that refers to the creators of PHP. But that
> particular joke has outworn its welcome in the community after repeatedly
> CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine)
>
>

I agree that it isn't the biggest issue in the world. If we had to give up
one of the more impactful changes in order to implement this, it would be a
different story. But that's not the case. There is no trade off here. The
RFC even contains the updates required, so it's not going to take up
anyone's time that could be spent on other features.

> "It's a minor change and an annoyance to a lot of people. Yes, by not
> changing this you’re annoying thousands of people." -Alexander Schrijver
>
> "It’s the same argument everyone else is giving, and really it all comes
> down to this.:
> Nostalgia is valued over clarity and consistency. Do you guys REALLY want
> to claim that?" -Chad Minick
>
> "...yes, it is broken, people have to Google or ask around for a very
> unclear error message when for the most part errors are (and should be)
> self explanatory
> ...Two things are broken: Either the token is named badly, or the token
> names shouldn’t show up in error messages at all and be replaced with
> something a bit more friendly.
> ...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on
> LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick
>
>

Honestly, I'm not a big fan of the following argument: "However, PHP is for
most people their first programming language and therefore may not have the
instinct to do an online search and will end up frustrated." - Googling is
such a core skill for programming, that if they can't figure that out, they
don't need to be programming.

However, that being said, I don't think that argument is even needed to
justify this RFC anyway.

The only place this MIGHT cause an issue is unit tests that are looking for
that specific string. While I'm not a fan of the "just use find/replace" to
update things argument, I think that's a perfectly valid one here, given
the uniqueness of the string being changed.

> Once again I plead for logic and sanity. At least have the courage to put
> it to a vote.
>
> On Wed, Jun 10, 2020, 12:28 PM Claude Pache <claude.pache@gmail.com>
> wrote:
>
> > 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 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 that I’ve most probably omitted
> or
> > mistyped some punctuation mark somewhere. However, PHP is unable to tell
> me
> > where exactly is the error: it tells only the line number, and I have to
> > carefully scan the entirely line to find the place. Sometimes, I resort
> to
> > split the offending line in several ones, so that I could get more
> precise
> > location info.
> >
> > So please, let the parser tell me not only the line of the error, but
> also
> > the column. Then, it doesn’t matter how the offending token is named if
> you
> > know where it is.
> >
> > —Claude
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

I have a reputation on this list for being rather conservative about
changes. I'm somewhat sympathetic to the symbolic reasons for keeping it
around. I don't think such reasons outweigh the benefits though. The only
valid solution I would support that didn't rename the token would be if we
removed that token from the error messages altogether. I think that would
be more likely to cause issues, though, since there could be tests that
need SOME sort of token specified.

--
Chase Peeler
chasepeeler@gmail.com

Sara Golemon

6 years ago

On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch <ryan.jentzsch@gmail.com>
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 for the most part errors are (and should be)
> self explanatory
>

You know what shows up unambiguously in a google search? "Paamayim
Nekudotayim".
You know what ISN'T unambiguous in a google search? "Double Colon"
You know who don't have an excuse to say "Google is hard"? Software
engineers.

> ...Two things are broken: Either the token is named badly, or the token
> names shouldn’t show up in error messages at all and be replaced with
> something a bit more friendly.
>

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.

Once again I plead for logic and sanity. At least have the courage to put

> it to a vote.
>
> Absolutely. Put it to a vote.  I've got my "no" all locked and loaded.

-Sara

Walter Parker

6 years ago

On Wed, Jun 10, 2020 at 3:14 PM Sara Golemon <pollita@php.net> wrote:

> On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch <ryan.jentzsch@gmail.com>
> 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 for the most part errors are (and should be)
> > self explanatory
> >
>
> You know what shows up unambiguously in a google search? "Paamayim
> Nekudotayim".
> You know what ISN'T unambiguous in a google search? "Double Colon"
> You know who don't have an excuse to say "Google is hard"? Software
> engineers.
>
>
> Can I say Double Thumbs Up to the comment about Google searches?

Anybody doing software development without using a search engine is typing
with one hand.
When making requests, stop inventing bad ideas.
Do you actually know developers that write software without ever using a
search engine to look up errors?
Given how most docs have moved online, that seems like people doing things
the hard way without good reason.
Assuming you have actually met these people, who have not even bothered to
even learn the basics of life in the modern age, why must we change to
support them?
Couldn't we just put a line in some doc somewhere about how using search
engines is a vital piece of development technology somewhere between using
print statements and how to use a debugger?

> > ...Two things are broken: Either the token is named badly, or the token
> > names shouldn’t show up in error messages at all and be replaced with
> > something a bit more friendly.
> >
>
> 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.
>
> Once again I plead for logic and sanity. At least have the courage to put
> > it to a vote.
> >
> > Absolutely. Put it to a vote.  I've got my "no" all locked and loaded.
>
> -Sara
>

--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Sebastian Bergmann

6 years ago

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

Zeev Suraski

6 years ago

On 11 Jun 2020, at 12:07, Sebastian Bergmann <sebastian@php.net> 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

Ben Ramsey

6 years ago

> On Jun 11, 2020, at 04:09, Zeev Suraski <zeev@zend.com> wrote:
>
>
> On 11 Jun 2020, at 12:07, Sebastian Bergmann <sebastian@php.net> 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

+1

I also like AllenJB’s suggestion A:

> a) Character count (at line 456, character 23)

Cheers,
Ben

Jakob Givoni

6 years ago

On Thu, Jun 11, 2020 at 12:14 AM Sara Golemon <pollita@php.net> 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 is self explanatory.

> 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.

>
> Once again I plead for logic and sanity. At least have the courage to put
> > it to a vote.
> >
> > Absolutely. Put it to a vote.  I've got my "no" all locked and loaded.

Why is this even an RFC? It's not a language change.
There seems to be consensus that those tokens should not be exposed in
error messages, so changing the name of one is not even a bugfix, it's
just an internal maintainability fix ;-)

If your position is "if it ain't broke, don't fix it", I think the
prudent thing to do would be to abstain from voting. If a change is
perceived as positive for at least one person and the rest are
indifferent, it's still a net positive change.

If your position is "error messages that you have to Google are better
than those you don't" then we should be seeing much more RFC proposing
to rename things like T_STRING to T_EMAFAI_ONAFAI_SAUKOFE etc. :-D

Best regards,
Jakob

Rowan Collins

6 years ago

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]

Rowan Collins

6 years ago

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 that I’ve most probably omitted or mistyped some punctuation mark somewhere.

I think this is a really good point, and I would like to expand on it:
rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure the
user never needs to see it.


A long time ago, PHP's parser errors were extremely cryptic, e.g.
"::::::::::" would tell you:

> Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

Since PHP 5.4 (according to https://3v4l.org/Hdjk8) the error message
includes the actual token encountered:

> Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM)

If I understand correctly, the current proposal will instead give us this:

> Parse error: syntax error, unexpected '::' (T_DOUBLE_COLON)

But why not simply this:

> Parse error: syntax error, unexpected '::'

Imagine you are a new PHP developer, who has only the vaguest idea of
what "parse" means; along with '::' (T_PAAMAYIM_NEKUDOTAYIM) you may
encounter such mysteries as these:

'<<' (T_SL)
'>>' (T_SR)
__NAMESPACE__ (T_NS_C)
''foo'' (T_CONSTANT_ENCAPSED_STRING) [which is a string, not a constant]
'foo' (T_STRING) [which is definitely not a string, but might be a constant]
... (T_ELLIPSIS) [a lot of people will misread this as "ellipse", a much
more common word]
** (T_POW) [is that the Star Trek character, or the rock band named
after her?]

Even straight-forward names like '==' (T_IS_EQUAL) are confusing - for
years I wondered what that "T_" meant, my experience with Delphi making
me guess at "type", which didn't make much sense.


I can see a small advantage of including something that is easy to
search for; but how often does the solution to a parse error depend on
exactly what the unexpected token was, so that searching for "Parse
error: syntax error, unexpected" wouldn't give enough of a hint?

Other information currently missing from the message - e.g. column
number, hints about unclosed blocks - is likely to be far more useful.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Rowan Collins

6 years ago

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
handful of places outside of parse errors that T_PAAMAYIM_NEKUDOTAYIM
might appear.

> If I understand correctly, the current proposal will instead give us
> this:
>
> > Parse error: syntax error, unexpected '::' (T_DOUBLE_COLON)
>
> But why not simply this:
>
> > Parse error: syntax error, unexpected '::'

To ensure I'm not making unreasonable demands of others, I had a go at
implementing this change, resulting in this straight-forward patch:
https://github.com/php/php-src/compare/master...IMSoP:parse-error-poc?diff=split

I believe there's code in zend_yytnamerr that could be tidied up if we
never want these token names, but also scope for other improvements in
the output - for instance, we might want to say "unexpected quoted
string 'foo'" instead of just "unexpected 'foo'".

There's also at least dozens of tests that will need to be changed to
account for the new messages.


However, it's enough to demonstrate the difference such a change would make:


Input
::::::::::::::::
Before
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM),
expecting end of file
After
Parse error: syntax error, unexpected '::', expecting end of file

Input
$$$$$$$$$
Before
Parse error: syntax error, unexpected end of file, expecting variable
(T_VARIABLE) or '{' or '$'
After
Parse error: syntax error, unexpected end of file, expecting variable or
'{' or '$'

Input
"foo" "bar"
Before
Parse error: syntax error, unexpected '"bar"' (T_CONSTANT_ENCAPSED_STRING)
After
Parse error: syntax error, unexpected '"bar"'


I think all of the above examples are easier to understand after than
before.

I would be interested to hear reasons not to pursue this idea further.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

AllenJB

6 years ago

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: https://wiki.php.net/rfc/rename-double-colon-token
>
> Although this token is a nod to the valuable contributions made by the
> Isrealie community we believe this token is rather confusing for newcomers.
> Moreso, as PHP is for many people their first programming language,
> they may not have some of the habits like googling errors when
> they are stuck, which leads to a frustrating experience.
>
> As we believe PHP still has many years of existence we think it is time
> to rename this token.
>
> This is backwards compatible with PHP 7 and 5.
> This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM
> and leaves this as a future scope.
>
> As the matter on hand is a relatively straight forward yes/no vote we expect
> it to be held after the minimum 2 week discussion period.
>
> Best regards
>
> George Peter Banyard

Either as an alternative, or as an "as well as" option: I think a better
way to improve parser error messages would be to include the point in
the line where the parser error occurred.  This would additionally help
where a token appears multiple times on the same line.

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 error occurred. I'm
not sure what the best way to do this would be - generically this could
be encapsulated in several values: The line content, token start
character count, token length / end character count

A case where I can see this still not helping is cases where the parse
error can occur several lines after the actual error (or even at the end
of the file) due to things like missing  quotes / braces.

AllenJB

Lynn

6 years ago

On Thu, Jun 11, 2020 at 10:45 AM AllenJB <php.lists@allenjb.me.uk> 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 error occurred. I'm
> not sure what the best way to do this would be - generically this could
> be encapsulated in several values: The line content, token start
> character count, token length / end character count
>

I really like the combination of A + C. After using php for 13 years the
error messages are still a bit cryptic at times, especially in legacy code
where you have a gazillion warnings in your IDE.

Regards,
Lynn

Stas Malyshev

6 years ago

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 - generically this could
>> be encapsulated in several values: The line content, token start
>> character count, token length / end character count
>>
>
> I really like the combination of A + C. After using php for 13 years the

If we could do the same as, for example, clang does: just display some
indication where the problem happened within the code, with the line
that caused it. Certainly not displaying internal token names, unless I
am debugging the parser they are useless.

--
Stas Malyshev
smalyshev@gmail.com

Guilliam Xavier

6 years ago

> 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) 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 - generically this could
> >> be encapsulated in several values: The line content, token start
> >> character count, token length / end character count
> >>
> >
> > I really like the combination of A + C. After using php for 13 years the
>
> If we could do the same as, for example, clang does: just display some
> indication where the problem happened within the code, with the line
> that caused it. Certainly not displaying internal token names, unless I
> am debugging the parser they are useless.
>

Could this be discussed rather in the "Improvement to errors" thread?
https://externals.io/message/110276