On 06/23/2011 08:08 PM, Felipe Pena wrote:
Patched:
Parse error: syntax error, unexpected end of file, expecting
'identifier' (T_STRING)
At least for developers who do not know how a compiler works, I think
that we should think about removing the information duplication of
"parse error" and
Thanks for the great work. More should be done on the front of helping
newcomers solve trivial issues imo.
On 23.06.2011 20:08, Felipe Pena wrote:
> $ sapi/cli/php -r 'class '
> Current:
> Parse error: syntax error, unexpected $end, expecting T_STRING
>
> Patched:
> Parse error: syntax error, une
2011/5/18 Gustavo Lopes :
> Em Tue, 17 May 2011 17:49:53 +0100, Stas Malyshev
> escreveu:
>
>> I think we need to keep token name in the message, since it makes it
>> easier to understand what parser expected if you need to debug the parser
>> (as opposed to your code). So I think we need to have
Hi!
On 6/23/11 11:08 AM, Felipe Pena wrote:
As can be noticed, I added the actual scanned string in the
"unexpected" part. This might be useful for finding really which makes
the parser error. (It was a bit tricky though :D)
Any thoughts?
https://wiki.php.net/rfc/improved-parser-error-message
On Thu, Jun 23, 2011 at 7:16 PM, Jordi Boggiano wrote:
> Thanks for the great work. More should be done on the front of helping
> newcomers solve trivial issues imo.
>
> On 23.06.2011 20:08, Felipe Pena wrote:
> > $ sapi/cli/php -r 'class '
> > Current:
> > Parse error: syntax error, unexpected $
Em Tue, 17 May 2011 17:49:53 +0100, Stas Malyshev
escreveu:
I think we need to keep token name in the message, since it makes it
easier to understand what parser expected if you need to debug the
parser (as opposed to your code). So I think we need to have both the
human-readable name an
On 05/17/2011 09:58 AM, Ferenc Kovacs wrote:
On Tue, May 17, 2011 at 6:49 PM, Stas Malyshevwrote:
Hi!
I think we need to keep token name in the message, since it makes it easier
to understand what parser expected if you need to debug the parser (as
opposed to your code). So I think we need to
On Tue, May 17, 2011 at 6:49 PM, Stas Malyshev wrote:
> Hi!
>
> I think we need to keep token name in the message, since it makes it easier
> to understand what parser expected if you need to debug the parser (as
> opposed to your code). So I think we need to have both the human-readable
> name an
Hi!
I think we need to keep token name in the message, since it makes it
easier to understand what parser expected if you need to debug the
parser (as opposed to your code). So I think we need to have both the
human-readable name and the token name, as Andi suggested.
--
Stanislav Malyshev, S
+1 with Andi's improvement.
Gustavo - I realize it's not about changing the token's name, but nobody (=very
few) looks at the token names. The point is to keep the tradition of also
exposing this specific token name to the user, but still making it clear that
what was expected was :: - without
Em Tue, 17 May 2011 17:07:09 +0100, Gustavo Lopes
escreveu:
[...]
Anyway, +1 to the change from you.
Sorry, it should read "from me".
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, May 17, 2011 at 6:01 PM, Andi Gutmans wrote:
> Hi Felipe,
>
> Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and
> agreed to keep it as a historical landmark. Let's not have the discussion
> yet again within the same year. Google it just to see the # of mentions.
>
>
M
On Tue, 17 May 2011, Felipe Pena wrote:
> 2011/5/16 Felipe Pena
>
> > Hi all,
> > As I have proposed previously in an old thread... What about we name all
> > the tokens to have an improved parser error message? (i.e. anymore
> > T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages
Em Tue, 17 May 2011 17:01:26 +0100, Andi Gutmans escreveu:
Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and
agreed to keep it as a historical landmark. Let's not have the
discussion yet again within the same year. Google it just to see the #
of mentions.
What we cou
Hi Felipe,
Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and agreed
to keep it as a historical landmark. Let's not have the discussion yet again
within the same year. Google it just to see the # of mentions.
What we could do as a compromise between history and improving ma
15 matches
Mail list logo
