Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) 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 recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) 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. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Stan Vass -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
-Oorspronkelijk bericht- Van: Stan Vass [mailto:sv_for...@fmethod.com] Verzonden: maandag 1 november 2010 10:19 Aan: internals@lists.php.net Onderwerp: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON Urgentie: Laag It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) 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 recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) 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. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Stan Vass -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing. Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php's heritage. And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you 'forget' about it. And if you can't remember the meaning of something like that, I hardly doubt you'd be a decent programmer anyway. Regards, Dennis Haarbrink
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Agreed, and really - my experience is that googling non-standard error message usually give instant result. Googling for a common error message could become a big time investment pointing to different software even if you point to search engine for what software to look. 2010/11/1 Dennis Haarbrink den...@born05.nl: -Oorspronkelijk bericht- Van: Stan Vass [mailto:sv_for...@fmethod.com] Verzonden: maandag 1 november 2010 10:19 Aan: internals@lists.php.net Onderwerp: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON Urgentie: Laag It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) 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 recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) 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. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Stan Vass -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing. Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php's heritage. And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you 'forget' about it. And if you can't remember the meaning of something like that, I hardly doubt you'd be a decent programmer anyway. Regards, Dennis Haarbrink -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 30 October 2010 01:47, admin ad...@codeangel.org wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. Chad Maybe, considering the easter egg nature of this token, one of the following URLs should be included in the message ... tinyurl.com/c8d7ek, tinyurl.com/25865ya or tinyurl.com/nlx98u. Maybe just drop the tinyurl.com part - let's give those that can't really something to complain about! -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Mon, Nov 01, 2010 at 10:58:36AM +0100, Dennis Haarbrink wrote: Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing. Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php's heritage. And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you 'forget' about it. And if you can't remember the meaning of something like that, I hardly doubt you'd be a decent programmer anyway. Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. This isn't an easteregg either. This is a lesson as someone explained. eastereggs aren't visible to normal users. If you want teach people about Hebrew you obviously can do so. I don't see how that is the goal of a programming language, but that is an other issue. But don't come along and insult us with this bullshit. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
+1 This solves lots of other problems we have and will have in the future. -- James Butler Sent from my iPhone On 1 Nov 2010, at 12:00, Stefan Marr p...@stefan-marr.de wrote: On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Mon, Nov 01, 2010 at 12:59:54PM +0100, Stefan Marr wrote: On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Right, and be forced to introduce some bullshit hebrew when its done. No, thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
-Original Message- From: Alexander Schrijver [mailto:alexander.schrij...@gmail.com] Sent: 01 November 2010 12:19 To: Stefan Marr Cc: Dennis Haarbrink; Stan Vass; internals@lists.php.net Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON On Mon, Nov 01, 2010 at 12:59:54PM +0100, Stefan Marr wrote: On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Right, and be forced to introduce some bullshit hebrew when its done. No, thank you. Err, the entire point is that it won't matter what the underlying token is. The error as seen can be anything you want it to be, or at least you can have a fight about what the new message looks like and i'm sure there won't really be a compelling reason for it to be in hebrew (unless localized). Please grow up... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [alexander.schrij...@gmail.com: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]
Oops, should've sent this to the list too. - Forwarded message from Alexander Schrijver alexander.schrij...@gmail.com - Date: Mon, 1 Nov 2010 13:28:59 +0100 From: Alexander Schrijver alexander.schrij...@gmail.com To: James Butler james.but...@edigitalresearch.com Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON User-Agent: Mutt/1.5.21 (2010-09-15) On Mon, Nov 01, 2010 at 12:23:07PM +, James Butler wrote: -Original Message- From: Alexander Schrijver [mailto:alexander.schrij...@gmail.com] Sent: 01 November 2010 12:19 To: Stefan Marr Cc: Dennis Haarbrink; Stan Vass; internals@lists.php.net Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON On Mon, Nov 01, 2010 at 12:59:54PM +0100, Stefan Marr wrote: On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Right, and be forced to introduce some bullshit hebrew when its done. No, thank you. Err, the entire point is that it won't matter what the underlying token is. The error as seen can be anything you want it to be, or at least you can have a fight about what the new message looks like and i'm sure there won't really be a compelling reason for it to be in hebrew (unless localized). Please grow up... It's the policy: There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually. Well, and a third reason, I like it. There is some reason this policy will change after i write this new tokenizer? - End forwarded message - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [alexander.schrij...@gmail.com: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]
On Nov 01 13:30:58, Alexander Schrijver wrote: Oops, should've sent this to the list too. - Forwarded message from Alexander Schrijver alexander.schrij...@gmail.com - Date: Mon, 1 Nov 2010 13:28:59 +0100 From: Alexander Schrijver alexander.schrij...@gmail.com To: James Butler james.but...@edigitalresearch.com Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON User-Agent: Mutt/1.5.21 (2010-09-15) On Mon, Nov 01, 2010 at 12:23:07PM +, James Butler wrote: -Original Message- From: Alexander Schrijver [mailto:alexander.schrij...@gmail.com] Sent: 01 November 2010 12:19 To: Stefan Marr Cc: Dennis Haarbrink; Stan Vass; internals@lists.php.net Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON On Mon, Nov 01, 2010 at 12:59:54PM +0100, Stefan Marr wrote: On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Right, and be forced to introduce some bullshit hebrew when its done. No, thank you. Err, the entire point is that it won't matter what the underlying token is. The error as seen can be anything you want it to be, or at least you can have a fight about what the new message looks like and i'm sure there won't really be a compelling reason for it to be in hebrew (unless localized). Please grow up... It's the policy: There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually. Well, and a third reason, I like it. There is some reason this policy will change after i write this new tokenizer? Yes, there is a reason: As it was explained before, lemon would not display token names but actual token values. So instead of Unexpected T_PAABLAH it would say Unexpected '::' ... Best, - End forwarded message - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [alexander.schrij...@gmail.com: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]
On Mon, Nov 01, 2010 at 01:36:24PM +0100, Etienne Kneuss wrote: It's the policy: There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually. Well, and a third reason, I like it. There is some reason this policy will change after i write this new tokenizer? Yes, there is a reason: As it was explained before, lemon would not display token names but actual token values. So instead of Unexpected T_PAABLAH it would say Unexpected '::' ... But the lesson Rasmus was telling us about would go away. Yet, this is one of the reasons the token is being kept. I am confused. Are you telling me this is a lesson for the programmers to be learned? Not for the users? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Mon, Nov 1, 2010 at 1:23 PM, James Butler james.but...@edigitalresearch.com wrote: -Original Message- From: Alexander Schrijver [mailto:alexander.schrij...@gmail.com] Sent: 01 November 2010 12:19 To: Stefan Marr Cc: Dennis Haarbrink; Stan Vass; internals@lists.php.net Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON On Mon, Nov 01, 2010 at 12:59:54PM +0100, Stefan Marr wrote: On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people. Instead of going for this cosmetic nonsense you should help those people on the lemon branch. I am insulted every time I have to read a parser token name in an error message, instead of a sensible error message. The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current mumbo-jumbo is completely insignificant compared to the cost of actually understanding the error message just indicating what the parser would have expected. Changing to lemon is the only way to actually achieve something in the long run... Right, and be forced to introduce some bullshit hebrew when its done. No, thank you. Err, the entire point is that it won't matter what the underlying token is. The error as seen can be anything you want it to be, or at least you can have a fight about what the new message looks like and i'm sure there won't really be a compelling reason for it to be in hebrew (unless localized). Please grow up... We don't know that when will the lemon switch be merged With that merged, what will be used for the double colon error? If we keep the constant as is, but show some the correct english error message, then this can be a solution. But with that, the whole educational and easter egg thingy will be gone IMO, so if we chose that path, we could rename the T_PAAMAYIM_NEKUDOTAYIM right now. If we keep the hebrew error message(so that will be shown in the logs, etc.) after the lemon switch, then I can't see why should Alexander work on that issue, when it's not going to solve the problem? Tyrael
Re: [PHP-DEV] [alexander.schrij...@gmail.com: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]
On Mon, Nov 1, 2010 at 1:43 PM, Alexander Schrijver alexander.schrij...@gmail.com wrote: On Mon, Nov 01, 2010 at 01:36:24PM +0100, Etienne Kneuss wrote: It's the policy: There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually. Well, and a third reason, I like it. There is some reason this policy will change after i write this new tokenizer? Yes, there is a reason: As it was explained before, lemon would not display token names but actual token values. So instead of Unexpected T_PAABLAH it would say Unexpected '::' ... But the lesson Rasmus was telling us about would go away. Yet, this is one of the reasons the token is being kept. I am confused. Are you telling me this is a lesson for the programmers to be learned? Not for the users? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ive just brought up in the original thread, maybe we should go back there. Tyrael
Re: [PHP-DEV] [alexander.schrij...@gmail.com: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]
On Nov 01 13:43:14, Alexander Schrijver wrote: On Mon, Nov 01, 2010 at 01:36:24PM +0100, Etienne Kneuss wrote: It's the policy: There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually. Well, and a third reason, I like it. There is some reason this policy will change after i write this new tokenizer? Yes, there is a reason: As it was explained before, lemon would not display token names but actual token values. So instead of Unexpected T_PAABLAH it would say Unexpected '::' ... But the lesson Rasmus was telling us about would go away. Yet, this is one of the reasons the token is being kept. I am confused. Are you telling me this is a lesson for the programmers to be learned? Not for the users? I believe that what Rasmus meant is that a simple _renaming_ of this token was not justified. I don't think that he would be against a parser change that would bring much more to the table, solely because it would make this gem disappear (at least I hope). But then again, even though Felipe did an amazing job with this lemon switch, few problems still prevent this change from happening in a near future. Best, -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Stan Vass wrote: It's amazing to me this has become such a long discussion. The facts are simple: 1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) 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 recignizable to start with 3) Yes, to all who are not sure, more people know English than Hebrew. 4) 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. T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement. Makes sense, just alias it and change the error message thus keeping bc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Mon, Nov 1, 2010 at 2:10 PM, Nathan Rixham nrix...@gmail.com wrote: Makes sense, just alias it and change the error message thus keeping bc. Please just move on. Everything possible has been said already. If we feel like there are critical issues introduced by this error message, then we may fix it, at some point, or maybe not. So please just stop to feed this thread as nothing new has been said in the last 100 replies. Thanks for your understanding, Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #47643 - array_diff slowdown
Can we get some opinions on this. I'm willing to make the changes, but I
want to get some sort of consensus on this.
Basically I believe the problem is that patch 42838 should be reverted and
the documentation should be updated. Someone on IRC had disagreed with me
so I want more opinions before I do anything.
On Fri, Aug 27, 2010 at 4:01 AM, Lonny K lon...@gmail.com wrote:
I wanted to discuss this bug to try to get it resolved. I briefly
discussed this over ICQ and had differing opinions then the person I was
talking to, so naturally I wanted a bigger audience.
Quick summary of what's going on:
* 47643 is about array_diff being slow.
* This was caused by the patch for 42838
* The problem with 42838 is basically that 0 != '0'
* Here is the diff: http://www.lonnylot.com/42838.diff
The lines that causes the slowdown are:
- while (*ptrs[i] (0 (c =
diff_data_compare_func(ptrs[0], ptrs[i] TSRMLS_CC {
- ptrs[i]++;
+ while (*ptr (0 (c =
diff_data_compare_func(ptrs[0], ptr TSRMLS_CC {
+ ptr++;
}
I feel the fix should be reverting 42838 because I feel 42838 wasn't a code
issue, but a documentation issue. It is noted in some places that comparing
a string to an integer results in the string being changed to 0. That is the
issue in 42838 and b/c this is excepted in other places it should be
excepted here. The documentation should be updated to say to typecast your
comparison to (string) if it is going to be important to your code.
Re: [PHP-DEV] Re: Bug #47643 - array_diff slowdown
Hi, 2010/11/1 Lonny K lon...@gmail.com Can we get some opinions on this. I'm willing to make the changes, but I want to get some sort of consensus on this. Basically I believe the problem is that patch 42838 should be reverted and the documentation should be updated. Someone on IRC had disagreed with me so I want more opinions before I do anything. The slowdown on array_diff has been fixed right now. Thanks. -- Regards, Felipe Pena
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Fri, October 29, 2010 7:47 pm, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. -1 And I *have* done enough PHP support. :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
2010/11/1 Richard Lynch c...@l-i-e.com On Fri, October 29, 2010 7:47 pm, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. -1 Instead of renaming the token, I prefer to associate a literal string to each token, to have a legible error message, without the T_ being shown. For example, we could use in the Bison grammar file: %token T_PAAMAYIM_NEKUDOTAYIM :: So that the error message become: $ sapi/cli/php -r '::' Parse error: syntax error, unexpected :: in Command line code on line 1 Instead of the known unexpected T_PAAMAYIM_NEKUDOTAYIM one. -- Regards, Felipe Pena
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 11/1/10 1:47 PM, Felipe Pena wrote: 2010/11/1 Richard Lynch c...@l-i-e.com On Fri, October 29, 2010 7:47 pm, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. -1 Instead of renaming the token, I prefer to associate a literal string to each token, to have a legible error message, without the T_ being shown. For example, we could use in the Bison grammar file: %token T_PAAMAYIM_NEKUDOTAYIM :: So that the error message become: $ sapi/cli/php -r '::' Parse error: syntax error, unexpected :: in Command line code on line 1 Instead of the known unexpected T_PAAMAYIM_NEKUDOTAYIM one. Years and years ago that was the intent. I didn't think there was a clean way to do that in yacc though. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4 alpha
Hi, we're a bit further along now; and with the typehinting resolved (http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858) I want to start started with PHP 5.4 with the first alpha on Wednesday, November 24th. There are a few things that need sorting out and/or clarification: - Annotations - Lemon rewrite - APC in trunk I don't think we can sort out the latter two before the alpha/branching. For Lemon because the rewrite apparently makes things slower; and for APC because it's still quite a lot of work to make it even work with trunk. For each of those three points, I will reply to this mail with a summary, and some suggestions. Please reply to this mail only for something else than the above three mentioned topics. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4: Annotations
Hi! The RFC on annotations for PHP http://wiki.php.net/rfc/annotations suggests to add new syntax to the language to provide meta data for use in reflection. This sort of meta data is usually provided in the form of docblocks, which this RFC does *not* state isn't good enough. The discussion on the mailinglist did not provide a clear consensus for either for or against. We could put this up for a vote, but I feel that that is not useful right now, because a few issues needs to be sorted out first. First, where we actually require annotations (over the current practise of using docblocks); and secondly whether we really want to introduce another syntax into the PHP scanners and parsers. For now I would suggest that this proposal needs to be sorted out before we can even suggest of putting it in PHP 5.4. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4: Rewriting of the parser into Lemon
On Nov 01 15:33:59, Derick Rethans wrote: Hi! Work has been done on rewriting the PHP parser to Lemon in a specific branch: http://svn.php.net/viewvc/php/php-src/branches/LEMON/ Right now, the Lemon parser is not actually faster than the current bison parser, so I would suggest not to put this in PHP 5.4 until it performs at least as well as the current parser. Are there any possibilities for optimisation so far? I'd make the guess that it is slower due to the rule decomposition that we had to do to match bison's mid-rules syntax. We could surely optimize the decomposition but it would require a lot of rewrite in zend_compile.c, which is quite tricky to do. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4: Adding APC
On Mon, 1 Nov 2010, Derick Rethans wrote: I understand that the general idea is to bundle APC with a future version of PHP. Right now, APC doesn't really compile for trunk because of internal changes. However, for PHP 5.3 it's getting into a pretty good shape. In order to add APC, what does still need to be done? Actually, Kalle just pointed out that it compiles just fine. In that case, I think we should put it in trunk and in the 5.4 alpha. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Delegate type hint/checks to alternative locations (Re: [PHP-DEV] back to 5.4 alpha)
Hi,
2010/10/19 Derick Rethans der...@php.net
Hi!
On Sun, 5 Sep 2010, Derick Rethans wrote:
I've spend some more time on this, and have attached a new patch that:
- Removes the strict type verification, changing it back into typehints
only.
- Keeps the current syntax so that typehints create structures in the
function entries.
- Keeps the reflection API for the syntax, so that you can query the
typehints.
- Changed the API so that the verification function can also modify the
variables.
I've just committed that patch, the implements the 3 first elements from
this list. I've also updated my little extension to behave in the same
way as it did with the previous patch:
There is a BC in the changes, I don't know if it is expected for the next
version, at least it is very strange.
?php
class int { }
function f(int $a) { }
f(new int); // no error
f('foo'); // no error
f(null); // no error
?
--
Regards,
Felipe Pena
Re: [PHP-DEV] PHP 5.4 alpha
Hi! (http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858) I want to start started with PHP 5.4 with the first alpha on Wednesday, November 24th. There are a few things that need sorting I just wanted to remind we have ZendCon this week, which means some people who might have something to say about this are either busy, in travel, or both. Please keep this in mind. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4: Annotations
Hi Derick, I'm all for it. Although I have karma, I'm not an active PHP core contributor, but I would like to participate of such discussion, mainly because I have plenty experience with Annotations from another languages. I'll spend some time re-reading the entire Annotations thread and come up with another proposal at the right time. Regards, On Mon, Nov 1, 2010 at 8:33 PM, Derick Rethans der...@php.net wrote: Hi! The RFC on annotations for PHP http://wiki.php.net/rfc/annotations suggests to add new syntax to the language to provide meta data for use in reflection. This sort of meta data is usually provided in the form of docblocks, which this RFC does *not* state isn't good enough. The discussion on the mailinglist did not provide a clear consensus for either for or against. We could put this up for a vote, but I feel that that is not useful right now, because a few issues needs to be sorted out first. First, where we actually require annotations (over the current practise of using docblocks); and secondly whether we really want to introduce another syntax into the PHP scanners and parsers. For now I would suggest that this proposal needs to be sorted out before we can even suggest of putting it in PHP 5.4. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
