Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/29/2010 09:29 PM, James Butler wrote: I'll bite. Why should this be changed? Is it broken? Is it something that 1 second on google can't answer? If somebody is advanced enough to be using classes (I think about the only time you would use a double colon) then they should know what it means. -- James Butler Sent from my iPhone On 30 Oct 2010, at 02:51, Chad Emrysad...@codeangel.org wrote: The fact they have to google to figure out what it means, the error message fails at it's purpose. (Realistically it'll take longer than a second unless you got google hot keyed to your log reader). I Liked Stefan's idea in the previous thread to not put token names in the error messages anymore and replace them with something more meaningful for the user. However, since that never happened, this is a better/easier alternative for now. How many total hours of googling will we save developers for a 10 sec grep and replace? (not sure if it's that easy, but for the sake of the argument). I can see only positives by switching it out. can someone give me a light on how much it would actually cost to do that? Some negatives? I don't see the argument given to be entirely helpful because it's exactly what I am trying to point out as a problem, and the reason why we should change it. -- 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
The first google entry when you search for it gives you the answer. It is actually unbelievably easy to find the answer via search. If a new PHP developer can't find it then maybe they shouldn't be writing code. This is a piece of history from the PHP 3 days and think it adds some character, a story (and history) to PHP. Don't think we should take this out after a good 12 years. I would prefer this was not changed. Andi -Original Message- From: admin [mailto:ad...@codeangel.org] Sent: Friday, October 29, 2010 5:47 PM To: internals php list Subject: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON 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 -- 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] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
As you mention, PHP errors are token names. Users have to read the manual to understand them at first sight. Then, what's the matter in having a bit of fun and nostalgia naming the tokens ? Switching to meanful error messages would make your point though. Pierre. Le samedi 30 octobre 2010 à 01:17 -0500, Chad Emrys a écrit : On 10/29/2010 09:29 PM, James Butler wrote: I'll bite. Why should this be changed? Is it broken? Is it something that 1 second on google can't answer? If somebody is advanced enough to be using classes (I think about the only time you would use a double colon) then they should know what it means. -- James Butler Sent from my iPhone On 30 Oct 2010, at 02:51, Chad Emrysad...@codeangel.org wrote: The fact they have to google to figure out what it means, the error message fails at it's purpose. (Realistically it'll take longer than a second unless you got google hot keyed to your log reader). I Liked Stefan's idea in the previous thread to not put token names in the error messages anymore and replace them with something more meaningful for the user. However, since that never happened, this is a better/easier alternative for now. How many total hours of googling will we save developers for a 10 sec grep and replace? (not sure if it's that easy, but for the sake of the argument). I can see only positives by switching it out. can someone give me a light on how much it would actually cost to do that? Some negatives? I don't see the argument given to be entirely helpful because it's exactly what I am trying to point out as a problem, and the reason why we should change it. signature.asc Description: This is a digitally signed message part
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/30/2010 01:23 AM, Andi Gutmans wrote: The first google entry when you search for it gives you the answer. It is actually unbelievably easy to find the answer via search. If a new PHP developer can't find it then maybe they shouldn't be writing code. This is a piece of history from the PHP 3 days and think it adds some character, a story (and history) to PHP. Don't think we should take this out after a good 12 years. I would prefer this was not changed. Andi I don't see what is so endearing about a badly named token. -- 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 10/29/10 11:17 PM, Chad Emrys wrote: The fact they have to google to figure out what it means, the error message fails at it's purpose. (Realistically it'll take longer than a second unless you got google hot keyed to your log reader). I Liked Stefan's idea in the previous thread to not put token names in the error messages anymore and replace them with something more meaningful for the user. However, since that never happened, this is a better/easier alternative for now. How many total hours of googling will we save developers for a 10 sec grep and replace? (not sure if it's that easy, but for the sake of the argument). I can see only positives by switching it out. can someone give me a light on how much it would actually cost to do that? Some negatives? I don't see the argument given to be entirely helpful because it's exactly what I am trying to point out as a problem, and the reason why we should change it. 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. -Rasmus -- 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 10/30/2010 01:30 AM, Rasmus Lerdorf wrote: On 10/29/10 11:17 PM, Chad Emrys wrote: The fact they have to google to figure out what it means, the error message fails at it's purpose. (Realistically it'll take longer than a second unless you got google hot keyed to your log reader). I Liked Stefan's idea in the previous thread to not put token names in the error messages anymore and replace them with something more meaningful for the user. However, since that never happened, this is a better/easier alternative for now. How many total hours of googling will we save developers for a 10 sec grep and replace? (not sure if it's that easy, but for the sake of the argument). I can see only positives by switching it out. can someone give me a light on how much it would actually cost to do that? Some negatives? I don't see the argument given to be entirely helpful because it's exactly what I am trying to point out as a problem, and the reason why we should change it. 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. -Rasmus Well Rasmus, I wish you would hang out more in ##php on freenode. (I see you there every so often) But we do get that question about that thing a lot. And even some rage, and I have to cool them off with all the reasons you and Andi are giving me right now. But I am not convinced nostalgia or teaching the English speakers a lesson is a good reason to keep around a confusing error message. -- 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 10/30/2010 11:53 AM, Andi Gutmans wrote: I would prefer this was not changed. +1 (for the same reasons) -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- 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
Hi! I can see only positives by switching it out. can someone give me a light on how much it would actually cost to do that? Some negatives? I It would probably require bribing all the opponents, so the cost would be in high six digits (in $US) I guess. what I am trying to point out as a problem, and the reason why we should It's not a problem. A very mild irritation at best. -- 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] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/30/2010 01:36 AM, Stas Malyshev wrote: Hi! I can see only positives by switching it out. can someone give me a light on how much it would actually cost to do that? Some negatives? I It would probably require bribing all the opponents, so the cost would be in high six digits (in $US) I guess. Good thing this is FOSS! I only have to bribe who ever is approving patches/commits these days. what I am trying to point out as a problem, and the reason why we should It's not a problem. A very mild irritation at best. See my original message, you don't do enough support. :p -- 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 okt 2010, at 08:34, Sebastian Bergmann sebast...@php.net wrote: On 10/30/2010 11:53 AM, Andi Gutmans wrote: I would prefer this was not changed. +1 (for the same reasons) I agree with Andi, Rasmus and the other people in favor. This token name is part of the history of PHP and adds to it's uniqueness. But besides this: renaming the constant is probably not going to solve the problem (at least not anytime soon). Changing this constant would mean breaking BC (some people using the tokenizer extension might use it) and thus officially it should only be implemented in PHP-next. This means that the support requests will be coming in for a long time as it not even planned for release or anything. Suppose that this rename would happen in the next minor release: most shared hosts lag immensily with their installed PHP version and I reckon most questions come from inexperienced / starting developers working with / on said hosts. And this means it will again take a long time before you notice any effect. (not to mention that Linux distros also lag). (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Bottom line: I'd opt for keeping it. Kind regards, Mike van Riel -- 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
Den 2010 10 30 03:51 skrev Chad Emrys ad...@codeangel.org: * snip * What is in a name anyway? There's something VERY ironic about a statement like that given what you're asking for ... Regards Peter
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 30 October 2010 09:09, Mike Van Riel mike.vanr...@naenius.com wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Most of the people coming to ##php on freenode asking questions like that have a hard time learning (on their own or at all) - they expect to be spoonfed. Changing the token name might lower the frequency of this particular question, but it would have no overall effect on the number of people coming to ask questions they could get answered in two seconds by google. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- 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 10/30/2010 02:09 AM, Mike Van Riel wrote: On 30 okt 2010, at 08:34, Sebastian Bergmann sebast...@php.net wrote: On 10/30/2010 11:53 AM, Andi Gutmans wrote: I would prefer this was not changed. +1 (for the same reasons) I agree with Andi, Rasmus and the other people in favor. This token name is part of the history of PHP and adds to it's uniqueness. But besides this: renaming the constant is probably not going to solve the problem (at least not anytime soon). Changing this constant would mean breaking BC (some people using the tokenizer extension might use it) and thus officially it should only be implemented in PHP-next. This means that the support requests will be coming in for a long time as it not even planned for release or anything. Suppose that this rename would happen in the next minor release: most shared hosts lag immensily with their installed PHP version and I reckon most questions come from inexperienced / starting developers working with / on said hosts. And this means it will again take a long time before you notice any effect. (not to mention that Linux distros also lag). (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Bottom line: I'd opt for keeping it. Kind regards, Mike van Riel Just want to make this point: the length of time for it to take affect is not an argument for not implementing it. It'll come out when it's out. The sooner we implement it, the sooner we'll notice the effect. This goes for any change slanted for major release. (Also if I understand, there is a synonym in Tokenizer anyway so both would work and won't break BC, I just don't understand why the confusing name has to show up in error messages). -- 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 10/30/2010 02:11 AM, Peter Lind wrote: Den 2010 10 30 03:51 skrev Chad Emrys ad...@codeangel.org mailto:ad...@codeangel.org: * snip * What is in a name anyway? There's something VERY ironic about a statement like that given what you're asking for ... Regards Peter It was intentional ;p, glad you caught it.
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/30/2010 02:16 AM, Peter Lind wrote: On 30 October 2010 09:09, Mike Van Rielmike.vanr...@naenius.com wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Most of the people coming to ##php on freenode asking questions like that have a hard time learning (on their own or at all) - they expect to be spoonfed. Changing the token name might lower the frequency of this particular question, but it would have no overall effect on the number of people coming to ask questions they could get answered in two seconds by google. Regards Peter 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? -- 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 09:34, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 02:16 AM, Peter Lind wrote: On 30 October 2010 09:09, Mike Van Rielmike.vanr...@naenius.com wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Most of the people coming to ##php on freenode asking questions like that have a hard time learning (on their own or at all) - they expect to be spoonfed. Changing the token name might lower the frequency of this particular question, but it would have no overall effect on the number of people coming to ask questions they could get answered in two seconds by google. Regards Peter 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? I wasn't arguing for or against a switch, just providing some background. That said, people with no google skills bugging you on irc is a very poor excuse for change. As for the rest of the discussion, both sides seem to have merit, in my opinion. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- 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 02:51, Chad Emrys ad...@codeangel.org wrote: What is in a name anyway? Would a T_PAAMAYIM_NEKUDOTAYIM by any other name make a difference? -- 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] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/30/2010 10:01 AM, Richard Quadling wrote: On 30 October 2010 02:51, Chad Emrys ad...@codeangel.org wrote: What is in a name anyway? Would a T_PAAMAYIM_NEKUDOTAYIM by any other name make a difference? To provide a counterargument, it certainly would. I don't consider myself an inexperienced PHP developer and have certainly done some OO programming, yet I only recently stumbled upon this error. I must admit that it is confusing. Most of these error messages are descriptive enough that just glossing over the code allows me to fix the issue 4 out of 5 times. For this one I had to do a Google search to reaffirm that my PHP installation didn't become the victim of a corrupted filesystem. Regards, Jorrit -- 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 okt 2010, at 09:34, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 02:16 AM, Peter Lind wrote: On 30 October 2010 09:09, Mike Van Rielmike.vanr...@naenius.com wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Most of the people coming to ##php on freenode asking questions like that have a hard time learning (on their own or at all) - they expect to be spoonfed. Changing the token name might lower the frequency of this particular question, but it would have no overall effect on the number of people coming to ask questions they could get answered in two seconds by google. Regards Peter 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? If you are referring to my response, I believe I have given other arguments than your claim, as have others. The point is in the question: is it worth it? Do you think it is worth it to change something which works (functionally), has been there for 12 years and for the effort it takes to persuade people to want to change it? This all because people will have to google once in their carreer? Another solution might be to add a rule to an IRC bot to automatically provide the answer if the token name (and/or common misspellings) are mentioned. This would instantly solve the issue about support requests. Kind regards, Mike van Riel -- 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.10.2010 08:34, Chad Emrys wrote: Well Rasmus, I wish you would hang out more in ##php on freenode. (I see you there every so often) But we do get that question about that thing a lot. And even some rage, and I have to cool them off with all the reasons you and Andi are giving me right now. But I am not convinced nostalgia or teaching the English speakers a lesson is a good reason to keep around a confusing error message. Well, isn't the problem here more people asking on IRC rather than using a search engine before? Renaming will not solve that. ~danielj -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/standard/file.c branches/PHP_5_3/ext/standard/file.h branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c branches/PH
hi, Removing the From header for non ftp request sounds good as it is invalid. However I don't see the need to introduce a global ini setting. This kind of information are protocol specific and should be defined either manually in a context (as shown in the report reproduce code) or as a context option, for a given protocol. It is also wrong from a design point of view to add protocol options in this layer (the agent info was a mistake back then already). I would suggest to apply Richard's patch instead and revert this change. If we need to add more options to one protocol or another, then let do it, but in the protocol implementation. Thanks for your work! Cheers, 2010/10/29 Gustavo André dos Santos Lopes cataphr...@php.net: cataphract Fri, 29 Oct 2010 15:29:15 + Revision: http://svn.php.net/viewvc?view=revisionrevision=304985 Log: - Fixed bug #53198 (changing INI setting from with ini_set did not have any effect) #Made from a proper INI setting and bound it to a global variable. #Previously, it was simply read from the hash table with the parsed ini file #by using cfg_get_string (I wonder why this mechanism still exists...) Bug: http://bugs.php.net/53198 (Assigned) From: header sent on http request when using stream_context. Changed paths: U php/php-src/branches/PHP_5_3/NEWS U php/php-src/branches/PHP_5_3/ext/standard/file.c U php/php-src/branches/PHP_5_3/ext/standard/file.h U php/php-src/branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c U php/php-src/branches/PHP_5_3/ext/standard/http_fopen_wrapper.c A php/php-src/branches/PHP_5_3/ext/standard/tests/http/bug53198.phpt U php/php-src/trunk/ext/standard/file.c U php/php-src/trunk/ext/standard/file.h U php/php-src/trunk/ext/standard/ftp_fopen_wrapper.c U php/php-src/trunk/ext/standard/http_fopen_wrapper.c A php/php-src/trunk/ext/standard/tests/http/bug53198.phpt 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
RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/standard/file.c branches/PHP_5_3/ext/standard/file.h branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c branche
The From: header is actually valid in http (see section 14.21 of RFC 2616) and is appropriately used in PHP, as it is. Yes, this should arguably be a context option for http/ftp wrappers, though one could argue it's a global setting that happens to reflect on those wrappers. In any case, that is a matter outside the realm of bug fixing; I merely made the ini setting that currently exists work correctly. Sorry for the top posting. -original message- Subject: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/standard/file.c branches/PHP_5_3/ext/standard/file.h branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c branches/PHP_5_3/ext/standard/http_fopen_wrapper.c branches/PHP_5_3/ext From: Pierre Joye pierre@gmail.com Date: 2010-10-30 12:27 hi, Removing the From header for non ftp request sounds good as it is invalid. However I don't see the need to introduce a global ini setting. This kind of information are protocol specific and should be defined either manually in a context (as shown in the report reproduce code) or as a context option, for a given protocol. It is also wrong from a design point of view to add protocol options in this layer (the agent info was a mistake back then already). I would suggest to apply Richard's patch instead and revert this change. If we need to add more options to one protocol or another, then let do it, but in the protocol implementation. Thanks for your work! Cheers, 2010/10/29 Gustavo André dos Santos Lopes cataphr...@php.net: cataphract Fri, 29 Oct 2010 15:29:15 + Revision: http://svn.php.net/viewvc?view=revisionrevision=304985 Log: - Fixed bug #53198 (changing INI setting from with ini_set did not have any effect) #Made from a proper INI setting and bound it to a global variable. #Previously, it was simply read from the hash table with the parsed ini file #by using cfg_get_string (I wonder why this mechanism still exists...) Bug: http://bugs.php.net/53198 (Assigned) From: header sent on http request when using stream_context. Changed paths: U php/php-src/branches/PHP_5_3/NEWS U php/php-src/branches/PHP_5_3/ext/standard/file.c U php/php-src/branches/PHP_5_3/ext/standard/file.h U php/php-src/branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c U php/php-src/branches/PHP_5_3/ext/standard/http_fopen_wrapper.c A php/php-src/branches/PHP_5_3/ext/standard/tests/http/bug53198.phpt U php/php-src/trunk/ext/standard/file.c U php/php-src/trunk/ext/standard/file.h U php/php-src/trunk/ext/standard/ftp_fopen_wrapper.c U php/php-src/trunk/ext/standard/http_fopen_wrapper.c A php/php-src/trunk/ext/standard/tests/http/bug53198.phpt 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 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 Sat, Oct 30, 2010 at 06:50, Daniel Jänecke jaene...@gmx.li wrote: Well, isn't the problem here more people asking on IRC rather than using a search engine before? Renaming will not solve that. In this case, one might argue that it would. Instead of what's a T_PAAMAYIM_NEKUDOTAYIM? you would have, WTF IS A T_DOUBLE_COLON ERROR N Y R PHP DOODZ SO F'D UP ARGH LOLZ!!1! -- /Daniel P. Brown Network Infrastructure Manager Documentation, Webmaster Teams http://www.php.net/ -- 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
As a further reason, (not that I think that's it needed) When doing anything vaguely specialist, e.g engineering, medicine, sport, you require a precise set of terminology so two or more people can communicate clearly. The result of this is that if you want to play in a domain, you must be prepared to learn and use domain specific language/terms/acronyms. The double colon is example of this. We can lead the horse to water, but we can't make him drink. -- James Butler Sent from my iPhone -- 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 Fri, Oct 29, 2010 at 11:30:04PM -0700, Rasmus Lerdorf wrote: with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually. I don't know if i can make suggestions as an outsider. However, i really like the dutch language and it would be really cool if T_WHILE would be replaced with T_TERWIJL. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/standard/file.c branches/PHP_5_3/ext/standard/file.h branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c branche
hi, On Sat, Oct 30, 2010 at 3:43 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: The From: header is actually valid in http (see section 14.21 of RFC 2616) and is appropriately used in PHP, as it is. Yes, this should arguably be a context option for http/ftp wrappers, though one could argue it's a global setting that happens to reflect on those wrappers. In any case, that is a matter outside the realm of bug fixing; I merely made the ini setting that currently exists work correctly. Sorry for the top posting. This directive is documented only to be used with FTP. Yes it would be nice to fully support the HTTP RFC, but not by making this implementation more ugly. Also new features should go to trunk. I suggest to actually fix the reported bug and do the right changes and additions in trunk. 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
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/standard/file.c branches/PHP_5_3/ext/standard/file.h branches/PHP_5_3/ext/standard/ftp_fopen_wrapper.c branche
On Sat, 30 Oct 2010 16:56:36 +0100, Pierre Joye pierre@gmail.com wrote: This directive is documented only to be used with FTP. The documentation was wrong, and has also been fixed. According to the bug report, this directive has been used for http for the last 8 years. Yes it would be nice to fully support the HTTP RFC, but not by making this implementation more ugly. Also new features should go to trunk. I suggest to actually fix the reported bug and do the right changes and additions in trunk. I repeat, there were no additions here. The only bug in that report was that cfg_get_string was being used to retrieve the value of the ini directive, which is wrong because then PHP doesn't know anything about the directive expect by putting it in the hash table that results from ini parsing. In particular, ini_set cannot then be used to change the value of the directive through the script. In fact, after removing these usages of cfg_get_string, only two usages remain in php-src, both in PDO. Regards -- Gustavo Lopes -- 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 10/30/2010 05:50 AM, Daniel Jänecke wrote: On 30.10.2010 08:34, Chad Emrys wrote: Well Rasmus, I wish you would hang out more in ##php on freenode. (I see you there every so often) But we do get that question about that thing a lot. And even some rage, and I have to cool them off with all the reasons you and Andi are giving me right now. But I am not convinced nostalgia or teaching the English speakers a lesson is a good reason to keep around a confusing error message. Well, isn't the problem here more people asking on IRC rather than using a search engine before? Renaming will not solve that. ~danielj That is an easy one to argue: Yes it will. -- 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 10/30/2010 09:55 AM, Daniel Brown wrote: On Sat, Oct 30, 2010 at 06:50, Daniel Jäneckejaene...@gmx.li wrote: Well, isn't the problem here more people asking on IRC rather than using a search engine before? Renaming will not solve that. In this case, one might argue that it would. Instead of what's a T_PAAMAYIM_NEKUDOTAYIM? you would have, WTF IS A T_DOUBLE_COLON ERROR N Y R PHP DOODZ SO F'D UP ARGH LOLZ!!1! Most likely not, we don't get tons of questions about other parser errors, unless the person refuses to read the error message to begin with (Those can't be fixed, true. But this for those people that DO read the messages, which is greater number than what you guys lead on) -- 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 10/30/2010 09:55 AM, Daniel Brown wrote: On Sat, Oct 30, 2010 at 06:50, Daniel Jäneckejaene...@gmx.li wrote: Well, isn't the problem here more people asking on IRC rather than using a search engine before? Renaming will not solve that. In this case, one might argue that it would. Instead of what's a T_PAAMAYIM_NEKUDOTAYIM? you would have, WTF IS A T_DOUBLE_COLON ERROR N Y R PHP DOODZ SO F'D UP ARGH LOLZ!!1! Most likely not, we don't get tons of questions about other parser errors, unless the person refuses to read the error message to begin with (Those can't be fixed, true. But this for those people that DO read the messages, which is greater number than what you guys lead on) -- 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 10/30/2010 03:46 AM, Mike Van Riel wrote: On 30 okt 2010, at 09:34, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 02:16 AM, Peter Lind wrote: On 30 October 2010 09:09, Mike Van Rielmike.vanr...@naenius.com wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Most of the people coming to ##php on freenode asking questions like that have a hard time learning (on their own or at all) - they expect to be spoonfed. Changing the token name might lower the frequency of this particular question, but it would have no overall effect on the number of people coming to ask questions they could get answered in two seconds by google. Regards Peter 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? If you are referring to my response, I believe I have given other arguments than your claim, as have others. The point is in the question: is it worth it? Do you think it is worth it to change something which works (functionally), has been there for 12 years and for the effort it takes to persuade people to want to change it? This all because people will have to google once in their carreer? Another solution might be to add a rule to an IRC bot to automatically provide the answer if the token name (and/or common misspellings) are mentioned. This would instantly solve the issue about support requests. Kind regards, Mike van Riel I think it's more constructive to the language when we ask Why Not? rather than Why?I already mentioned in my first email: It is worth it. Automatic bot responses are prone to abuse. -- 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 Sat, Oct 30, 2010 at 12:35, Chad Emrys ad...@codeangel.org wrote: Most likely not, we don't get tons of questions about other parser errors, unless the person refuses to read the error message to begin with (Those can't be fixed, true. But this for those people that DO read the messages, which is greater number than what you guys lead on) I have to say, you certainly are sure of yourself when it comes to describing our opinions and actions, yet - aside from argue a point that has little chance of succeeding here, as you can tell - you've done nothing to give your point validity outside of your own experience and interpretations. You mentioned how great it was that PHP is FOSS, and that you'd only have to bribe whomever is handling patch reviews and submissions. Another great thing about FOSS: your right to fork. -- /Daniel P. Brown Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting (866-) 725-4321 http://www.parasane.net/ -- 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
If it ain't broken don't fix it. Change for the sake of it is a bad thing. It does things like introduce bugs etc. Q1) is it broken? Q2) if yes exactly what is broken Q3) does the proposes fix solve the root cause? I'm not sure changing the token name is the correct fix to people not knowing what the error means. -- James Butler Sent from my iPhone -- 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 10/30/2010 11:41 AM, Daniel P. Brown wrote: On Sat, Oct 30, 2010 at 12:35, Chad Emrysad...@codeangel.org wrote: Most likely not, we don't get tons of questions about other parser errors, unless the person refuses to read the error message to begin with (Those can't be fixed, true. But this for those people that DO read the messages, which is greater number than what you guys lead on) I have to say, you certainly are sure of yourself when it comes to describing our opinions and actions, yet - aside from argue a point that has little chance of succeeding here, as you can tell - you've done nothing to give your point validity outside of your own experience and interpretations. You mentioned how great it was that PHP is FOSS, and that you'd only have to bribe whomever is handling patch reviews and submissions. Another great thing about FOSS: your right to fork. It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the exact same argument over and over again that I believe is not a very good argument (They can just google it thing). Some other people have provided other arguments as well and those are more valued. (Though I don't think they are strong enough reasons yet NOT to do it). Forking won't fix this particular problem. -- 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 10/30/2010 11:43 AM, James Butler wrote: If it ain't broken don't fix it. Change for the sake of it is a bad thing. It does things like introduce bugs etc. Q1) is it broken? Q2) if yes exactly what is broken Q3) does the proposes fix solve the root cause? I'm not sure changing the token name is the correct fix to people not knowing what the error means. -- James Butler Sent from my iPhone Q1) yes, it is broken, people have to Google or ask around for a very unclear error message when for the most parts errors are (and should be) self explanatory. Q2) 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. Q3) those two fixes above would probably fix that, yes. 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? because they DO. -- 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 Sat, Oct 30, 2010 at 12:47, Chad Emrys ad...@codeangel.org wrote: It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the exact same argument over and over again that I believe is not a very good argument (They can just google it thing). Some other people have provided other arguments as well and those are more valued. (Though I don't think they are strong enough reasons yet NOT to do it). It does have merit --- to you, and perhaps a few others. Hopefully without sounding like I'm ridiculing you (it's not my intent), have you seriously considered this at all, and are you realizing that it's just not going to happen at this time? I mean, if you submitted a request or implementation proposal for an INI-based option to switch between token strings and expanded help messages, that would likely receive more serious attention than the dismissive responses and formed opinions of your own insight as based upon this discussion. Forking won't fix this particular problem. Well, if your statement about how no one here who disagrees with you does enough support (which is, quite frankly, an asinine assessment), then an equal rebuttal will be that you do not know enough about the inner workings of the software you claim to support, nor the culture of the group who maintains it. You're taking a minor annoyance and trying to convince the masses - and indeed the powers that be - that it is tantamount to Y2K38. Again, I'm really not trying to insult you or your original opinion here, Chad, but the continued arguments are almost coming off as silly now. -- /Daniel P. Brown Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting (866-) 725-4321 http://www.parasane.net/ -- 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 10/30/2010 11:58 AM, Daniel P. Brown wrote: On Sat, Oct 30, 2010 at 12:47, Chad Emrysad...@codeangel.org wrote: It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the exact same argument over and over again that I believe is not a very good argument (They can just google it thing). Some other people have provided other arguments as well and those are more valued. (Though I don't think they are strong enough reasons yet NOT to do it). It does have merit --- to you, and perhaps a few others. Hopefully without sounding like I'm ridiculing you (it's not my intent), have you seriously considered this at all, and are you realizing that it's just not going to happen at this time? I mean, if you submitted a request or implementation proposal for an INI-based option to switch between token strings and expanded help messages, that would likely receive more serious attention than the dismissive responses and formed opinions of your own insight as based upon this discussion. Forking won't fix this particular problem. Well, if your statement about how no one here who disagrees with you does enough support (which is, quite frankly, an asinine assessment), then an equal rebuttal will be that you do not know enough about the inner workings of the software you claim to support, nor the culture of the group who maintains it. You're taking a minor annoyance and trying to convince the masses - and indeed the powers that be - that it is tantamount to Y2K38. Again, I'm really not trying to insult you or your original opinion here, Chad, but the continued arguments are almost coming off as silly now. If you haven't noticed, I am a bit stubborn, yes it's a problem. When I submitted this proposal, I have to at least try to plant a bug in their brain that perhaps, they are being to hasty on dismissing this argument. True, I do not know a lot about this particular culture that maintains PHP. I just know the bigger culture of those who use PHP, and some of them are quite annoyed by the dismissive nature of the maintainers who are quite at odds to what the majority of the community want or needs. And I am sort of glad to annoy those who are overly dismissive, and hopefully ploy the one's who are on the fence. No one said I was good at politics. But the fact one has to play the politics game here to get anything worth while doesn't really phase me. Now I am starting to find this argument straying from the point. I don't believe attacking me personally or me attacking the nature of this mailing list really has to do with the subject line. -- 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 19:18, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 11:58 AM, Daniel P. Brown wrote: On Sat, Oct 30, 2010 at 12:47, Chad Emrysad...@codeangel.org wrote: It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the exact same argument over and over again that I believe is not a very good argument (They can just google it thing). Some other people have provided other arguments as well and those are more valued. (Though I don't think they are strong enough reasons yet NOT to do it). It does have merit --- to you, and perhaps a few others. Hopefully without sounding like I'm ridiculing you (it's not my intent), have you seriously considered this at all, and are you realizing that it's just not going to happen at this time? I mean, if you submitted a request or implementation proposal for an INI-based option to switch between token strings and expanded help messages, that would likely receive more serious attention than the dismissive responses and formed opinions of your own insight as based upon this discussion. Forking won't fix this particular problem. Well, if your statement about how no one here who disagrees with you does enough support (which is, quite frankly, an asinine assessment), then an equal rebuttal will be that you do not know enough about the inner workings of the software you claim to support, nor the culture of the group who maintains it. You're taking a minor annoyance and trying to convince the masses - and indeed the powers that be - that it is tantamount to Y2K38. Again, I'm really not trying to insult you or your original opinion here, Chad, but the continued arguments are almost coming off as silly now. If you haven't noticed, I am a bit stubborn, yes it's a problem. When I submitted this proposal, I have to at least try to plant a bug in their brain that perhaps, they are being to hasty on dismissing this argument. True, I do not know a lot about this particular culture that maintains PHP. I just know the bigger culture of those who use PHP, and some of them are quite annoyed by the dismissive nature of the maintainers who are quite at odds to what the majority of the community want or needs. And I am sort of glad to annoy those who are overly dismissive, and hopefully ploy the one's who are on the fence. No one said I was good at politics. But the fact one has to play the politics game here to get anything worth while doesn't really phase me. Now I am starting to find this argument straying from the point. I don't believe attacking me personally or me attacking the nature of this mailing list really has to do with the subject line. Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems to me that might get a lot more traction. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- 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 Sat, Oct 30, 2010 at 12:18 PM, Chad Emrys ad...@codeangel.org wrote: I just know the bigger culture of those who use PHP, and some of them are quite annoyed by the dismissive nature of the maintainers who are quite at odds to what the majority of the community want or needs. As one of those people who use PHP, after the first time googling it, I haven't needed it. It's one of those things about the language that's interesting. If you're going to complain about how someone has to learn something about another culture, why not take a step back and consider those throughout the world whose native language is something other than English have to try to translate what it does. Also, as one who also answers other's questions (although not IRC, because its my experience most people asking questions on there are dbags), I find that complaints regarding PHP's ambiguity in naming conventions and variable order (which is slowly being fixed, and is greatly appreciated) far, far outnumber the complaints regarding T_PAAMAYIM_NEKUDOTAYIM. Actually, I never hear complaints about T_PAAMAYIM_NEKUDOTAYIM, just questions about what it is by people who'd rather be told than find out for themselves. And, when they find out, the answer is usually something like Oh, neat. And, what sort of cooperation do you expect to get when your first line is WTF is T_PAAMAYIM_NEKUDOTAYIM?. That's akin to finding multiple languages on your tax forms and exclaiming WTF is this doing here!? -- Jack Timmons @_Codeacula Trollfree: 8503290326 -- 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 Sat, 30 Oct 2010 12:44:41 -0500 Jack Timmons codeac...@codeacula.com wrote: Also, as one who also answers other's questions (although not IRC, because its my experience most people asking/*answering* questions on there are dbags), FTFY. -- 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
Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution. If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really) This is not meant to bait but possibly an improvement in your support process or docs might yield a solution? -- James Butler Sent from my iPhone On 30 Oct 2010, at 17:51, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 11:43 AM, James Butler wrote: If it ain't broken don't fix it. Change for the sake of it is a bad thing. It does things like introduce bugs etc. Q1) is it broken? Q2) if yes exactly what is broken Q3) does the proposes fix solve the root cause? I'm not sure changing the token name is the correct fix to people not knowing what the error means. -- James Butler Sent from my iPhone Q1) yes, it is broken, people have to Google or ask around for a very unclear error message when for the most parts errors are (and should be) self explanatory. Q2) 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. Q3) those two fixes above would probably fix that, yes. 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? because they DO. -- 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 10/30/2010 01:02 PM, James Butler wrote: Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution. If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really) This is not meant to bait but possibly an improvement in your support process or docs might yield a solution? -- James Butler Sent from my iPhone On 30 Oct 2010, at 17:51, Chad Emrysad...@codeangel.org wrote: No I support a general PHP support community. We help everywhere from beginners to seasoned experts, and probably help around hundreds of people a day. -- 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 10/30/2010 12:57 PM, Mark Skilbeck wrote: On Sat, 30 Oct 2010 12:44:41 -0500 Jack Timmonscodeac...@codeacula.com wrote: Also, as one who also answers other's questions (although not IRC, because its my experience most people asking/*answering* questions on there are dbags), FTFY. That's just rude, dude. -- 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 10/30/2010 12:44 PM, Jack Timmons wrote: On Sat, Oct 30, 2010 at 12:18 PM, Chad Emrysad...@codeangel.org wrote: I just know the bigger culture of those who use PHP, and some of them are quite annoyed by the dismissive nature of the maintainers who are quite at odds to what the majority of the community want or needs. As one of those people who use PHP, after the first time googling it, I haven't needed it. It's one of those things about the language that's interesting. If you're going to complain about how someone has to learn something about another culture, why not take a step back and consider those throughout the world whose native language is something other than English have to try to translate what it does. Also, as one who also answers other's questions (although not IRC, because its my experience most people asking questions on there are dbags), I find that complaints regarding PHP's ambiguity in naming conventions and variable order (which is slowly being fixed, and is greatly appreciated) far, far outnumber the complaints regarding T_PAAMAYIM_NEKUDOTAYIM. Actually, I never hear complaints about T_PAAMAYIM_NEKUDOTAYIM, just questions about what it is by people who'd rather be told than find out for themselves. And, when they find out, the answer is usually something like Oh, neat. And, what sort of cooperation do you expect to get when your first line is WTF is T_PAAMAYIM_NEKUDOTAYIM?. That's akin to finding multiple languages on your tax forms and exclaiming WTF is this doing here!? I'm not arguing about learning another culture. The argument is that an error message that should be straight forward, isn't. I wouldn't be here if the error message was something like: unexpected T_PAAMAYIM_NEKUDOTAYIM on line 23 (PAAMAYIM NEKUDOTAYIM is hebrew for double colon because a lot of great Israelites helped make what PHP is today) :p Also that first line is just a sample of what I got to deal with on a day to day basis. -- 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 10/30/2010 12:44 PM, Peter Lind wrote: On 30 October 2010 19:18, Chad Emrysad...@codeangel.org wrote: On 10/30/2010 11:58 AM, Daniel P. Brown wrote: On Sat, Oct 30, 2010 at 12:47, Chad Emrysad...@codeangel.orgwrote: It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the exact same argument over and over again that I believe is not a very good argument (They can just google it thing). Some other people have provided other arguments as well and those are more valued. (Though I don't think they are strong enough reasons yet NOT to do it). It does have merit --- to you, and perhaps a few others. Hopefully without sounding like I'm ridiculing you (it's not my intent), have you seriously considered this at all, and are you realizing that it's just not going to happen at this time? I mean, if you submitted a request or implementation proposal for an INI-based option to switch between token strings and expanded help messages, that would likely receive more serious attention than the dismissive responses and formed opinions of your own insight as based upon this discussion. Forking won't fix this particular problem. Well, if your statement about how no one here who disagrees with you does enough support (which is, quite frankly, an asinine assessment), then an equal rebuttal will be that you do not know enough about the inner workings of the software you claim to support, nor the culture of the group who maintains it. You're taking a minor annoyance and trying to convince the masses - and indeed the powers that be - that it is tantamount to Y2K38. Again, I'm really not trying to insult you or your original opinion here, Chad, but the continued arguments are almost coming off as silly now. If you haven't noticed, I am a bit stubborn, yes it's a problem. When I submitted this proposal, I have to at least try to plant a bug in their brain that perhaps, they are being to hasty on dismissing this argument. True, I do not know a lot about this particular culture that maintains PHP. I just know the bigger culture of those who use PHP, and some of them are quite annoyed by the dismissive nature of the maintainers who are quite at odds to what the majority of the community want or needs. And I am sort of glad to annoy those who are overly dismissive, and hopefully ploy the one's who are on the fence. No one said I was good at politics. But the fact one has to play the politics game here to get anything worth while doesn't really phase me. Now I am starting to find this argument straying from the point. I don't believe attacking me personally or me attacking the nature of this mailing list really has to do with the subject line. Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems to me that might get a lot more traction. Regards Peter I actually know Etienne, he does spend some of his time fighting the good fight of supporting PHP :p. Anyway he has said the lemon parser project is going kind of slow as it is proving to be more difficult because some of the weirdness in PHP. (Don't ask me what that means.) Maybe more help should be put into that effort? -- 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 22:13, Chad Emrys ad...@codeangel.org wrote: *snip* I actually know Etienne, he does spend some of his time fighting the good fight of supporting PHP :p. Anyway he has said the lemon parser project is going kind of slow as it is proving to be more difficult because some of the weirdness in PHP. (Don't ask me what that means.) Maybe more help should be put into that effort? That was my point: perhaps that would be a less futile fight than trying to persuade people that t_paamayim_nekudotayim should be renamed. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- 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 10/30/2010 03:21 PM, Peter Lind wrote: On 30 October 2010 22:13, Chad Emrysad...@codeangel.org wrote: *snip* I actually know Etienne, he does spend some of his time fighting the good fight of supporting PHP :p. Anyway he has said the lemon parser project is going kind of slow as it is proving to be more difficult because some of the weirdness in PHP. (Don't ask me what that means.) Maybe more help should be put into that effort? That was my point: perhaps that would be a less futile fight than trying to persuade people that t_paamayim_nekudotayim should be renamed. Regards Peter Perhaps you are right. Most constructive thing said in this thread yet. -- 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 10/30/2010 03:21 PM, Peter Lind wrote: On 30 October 2010 22:13, Chad Emrysad...@codeangel.org wrote: *snip* I actually know Etienne, he does spend some of his time fighting the good fight of supporting PHP :p. Anyway he has said the lemon parser project is going kind of slow as it is proving to be more difficult because some of the weirdness in PHP. (Don't ask me what that means.) Maybe more help should be put into that effort? That was my point: perhaps that would be a less futile fight than trying to persuade people that t_paamayim_nekudotayim should be renamed. Regards Peter Perhaps you are right. Most constructive thing said in this thread yet. -- 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 Oct 30 19:44:08, Peter Lind wrote: On 30 October 2010 19:18, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 11:58 AM, Daniel P. Brown wrote: On Sat, Oct 30, 2010 at 12:47, Chad Emrysad...@codeangel.org wrote: It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the exact same argument over and over again that I believe is not a very good argument (They can just google it thing). Some other people have provided other arguments as well and those are more valued. (Though I don't think they are strong enough reasons yet NOT to do it). It does have merit --- to you, and perhaps a few others. Hopefully without sounding like I'm ridiculing you (it's not my intent), have you seriously considered this at all, and are you realizing that it's just not going to happen at this time? I mean, if you submitted a request or implementation proposal for an INI-based option to switch between token strings and expanded help messages, that would likely receive more serious attention than the dismissive responses and formed opinions of your own insight as based upon this discussion. Forking won't fix this particular problem. Well, if your statement about how no one here who disagrees with you does enough support (which is, quite frankly, an asinine assessment), then an equal rebuttal will be that you do not know enough about the inner workings of the software you claim to support, nor the culture of the group who maintains it. You're taking a minor annoyance and trying to convince the masses - and indeed the powers that be - that it is tantamount to Y2K38. Again, I'm really not trying to insult you or your original opinion here, Chad, but the continued arguments are almost coming off as silly now. If you haven't noticed, I am a bit stubborn, yes it's a problem. When I submitted this proposal, I have to at least try to plant a bug in their brain that perhaps, they are being to hasty on dismissing this argument. True, I do not know a lot about this particular culture that maintains PHP. I just know the bigger culture of those who use PHP, and some of them are quite annoyed by the dismissive nature of the maintainers who are quite at odds to what the majority of the community want or needs. And I am sort of glad to annoy those who are overly dismissive, and hopefully ploy the one's who are on the fence. No one said I was good at politics. But the fact one has to play the politics game here to get anything worth while doesn't really phase me. Now I am starting to find this argument straying from the point. I don't believe attacking me personally or me attacking the nature of this mailing list really has to do with the subject line. Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems to me that might get a lot more traction. lemon would indeed get rid of actual names for such tokens, and would rather display unnexpected ::. The problem with lemon is that it turns out to still be a tad bit slower than yacc, with some complications on the grammar side (the compiler helper functions were made for yacc). So unless there is a major speedup breakthrough, it won't happen in a near future, sadly. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- 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] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/30/2010 03:32 PM, Etienne Kneuss wrote: lemon would indeed get rid of actual names for such tokens, and would rather display unnexpected ::. The problem with lemon is that it turns out to still be a tad bit slower than yacc, with some complications on the grammar side (the compiler helper functions were made for yacc). So unless there is a major speedup breakthrough, it won't happen in a near future, sadly. So does that leave us back to square 1 with replacing the token name? Or is there another way that error messages can be tweaked to not show actual token names? -- 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
From a completely separate stand point. The ability to customise what token names show up as in an error seems like a much better solution -- James Butler Sent from my iPhone On 30 Oct 2010, at 21:41, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 03:32 PM, Etienne Kneuss wrote: lemon would indeed get rid of actual names for such tokens, and would rather display unnexpected ::. The problem with lemon is that it turns out to still be a tad bit slower than yacc, with some complications on the grammar side (the compiler helper functions were made for yacc). So unless there is a major speedup breakthrough, it won't happen in a near future, sadly. So does that leave us back to square 1 with replacing the token name? Or is there another way that error messages can be tweaked to not show actual token names? -- 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] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Sat, Oct 30, 2010 at 3:10 PM, Chad Emrys ad...@codeangel.org wrote: I'm not arguing about learning another culture. The argument is that an error message that should be straight forward, isn't. You misunderstand my point. It isn't straightforward for -you- because that isn't your native language. Thus the cultural point. But if switched to T_DOUBLE_COLON, then others who don't know English could then argue it isn't straight forward. It's an entirely pedantic point to argue, I agree, but thus far you entire complain was because it isn't in English, and you want it changed so you don't have to hear about it constantly. The fact is, it says double colon in a different language, so aside from translation there's nothing wrong with it at all. Magic would be internationalizing the error messages, but then there will be someone whose language doesn't have a version. -- Jack Timmons @_Codeacula Trollfree: 8503290326 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php