Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Ryan Panning
Ilia Alshanetsky wrote: Another issue I just came across caused by :: being used for both namespaces and classes is the fact when it comes to validation such as the one I've just put it for constant names, its impossible to determine if the prefix is a namespace or a class name. So, I definitel

RE: [PHP-DEV] str_getcsv

2008-10-20 Thread Johannes Schlüter
On Mon, 2008-10-20 at 22:03 +0100, Steve Hanselman wrote: > If it's not stupid question, what is the main branch for? Presumably > the other branches aren't just branched from this at a point in time > or we'd have this in there. The "main" branch? PHP_5_X are the "stable" branches, "HEAD" is the

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Ilia Alshanetsky
Another issue I just came across caused by :: being used for both namespaces and classes is the fact when it comes to validation such as the one I've just put it for constant names, its impossible to determine if the prefix is a namespace or a class name. So, I definitely think we should ch

Re: [PHP-DEV] str_getcsv

2008-10-20 Thread Lukas Kahwe Smith
On 20.10.2008, at 23:07, Ilia Alshanetsky wrote: On 20-Oct-08, at 4:46 PM, Hannes Magnusson wrote: On Mon, Oct 20, 2008 at 22:43, Steve Hanselman <[EMAIL PROTECTED]> wrote: Can anybody suggest a reason why this has never moved from main to php_5_2 or php_5_3? I did wonder the same month

Re: [PHP-DEV] str_getcsv

2008-10-20 Thread Ilia Alshanetsky
On 20-Oct-08, at 4:46 PM, Hannes Magnusson wrote: On Mon, Oct 20, 2008 at 22:43, Steve Hanselman <[EMAIL PROTECTED]> wrote: Can anybody suggest a reason why this has never moved from main to php_5_2 or php_5_3? I did wonder the same months ago, but noone seemed to care, and I had no use fo

RE: [PHP-DEV] str_getcsv

2008-10-20 Thread Steve Hanselman
If it's not stupid question, what is the main branch for? Presumably the other branches aren't just branched from this at a point in time or we'd have this in there. High? Nah, just chilled after a glass or two of wine. Can't beat a good corporate disclaimer! Steve

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Steph Fox
I wasn't planning to open the ns separator discussion again. In fact I think we'd all much rather avoid it completely... As info, in a Spanish keyboard it's the same, Alt Gr+{the key to the left of the 1}. ... but thanks for that part of your input (and same to Ólafur). - Steph -- PHP Inte

Re: [PHP-DEV] str_getcsv

2008-10-20 Thread Hannes Magnusson
On Mon, Oct 20, 2008 at 22:43, Steve Hanselman <[EMAIL PROTECTED]> wrote: > Can anybody suggest a reason why this has never moved from main to php_5_2 or > php_5_3? I did wonder the same months ago, but noone seemed to care, and I had no use for it myself so I never bothered merging it :) > The

[PHP-DEV] str_getcsv

2008-10-20 Thread Steve Hanselman
Can anybody suggest a reason why this has never moved from main to php_5_2 or php_5_3? It was added to MAIN in dec '06 Steve The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Federico Lebron
Ólafur Waage wrote: On an icelandic keyboard "\" is AltGr + (key right of 0 in the top row), just an fyi if you guys wanted to know. For my two cents. "\" looks like its not supposed to be there. Is there no other combination of two simbols that would work? Like >> or +> or ** or .. or somethin

Re: [PHP-DEV] An optimization idea

2008-10-20 Thread shire
On Oct 19, 2008, at 12:11 PM, Karoly Negyesi wrote: Hi, I think zend_hash_compare could get a healthy speed boost in some cases if first it would check whether the two variables passed to it are actually the same (because of "reference counting"). Sorry, my C skills are way too rusty to write

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Ólafur Waage
On an icelandic keyboard "\" is AltGr + (key right of 0 in the top row), just an fyi if you guys wanted to know. For my two cents. "\" looks like its not supposed to be there. Is there no other combination of two simbols that would work? Like >> or +> or ** or .. or something in that fashion ? Ó

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Steph Fox
The "german keyboard" issue isn't really one. {}[] are in the same "class" of characters (alt-Gr + number-row). So, as a programmer, you either have to live with that anyway because there's no avoiding {}[], or you switch to the us layout while programming (which quite a few people do). Also

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Stefan Walk
On Monday 20 October 2008 20:42:36 Steph Fox wrote: > > Well, on German keyboards, it's accessible but only by using ALTGR+?, > > which is not really a comfortable combination. > > Useful to know, thanks Philipp. > > Any more localized keyboard issues we should know about? Anyone? > > - Steph The

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Steph Fox
Well, on German keyboards, it's accessible but only by using ALTGR+?, which is not really a comfortable combination. Useful to know, thanks Philipp. Any more localized keyboard issues we should know about? Anyone? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] Namespace issues

2008-10-20 Thread Philipp Wagner
Hi, Steph Fox wrote: > Hi Lester, > >> And there are no problems with those on foreign keyboards? > > If there are, those foreign keyboards are unable to offer either escaped > chars or MS paths... which seems highly unlikely. Well, on German keyboards, it's accessible but only by using ALTGR+?

[PHP-DEV] PHP 6 Bug Summary Report

2008-10-20 Thread internals
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (68 total -- which includes 31 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===

Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set using header()

2008-10-20 Thread Hannes Magnusson
On Sun, Oct 19, 2008 at 23:41, Christian Schmidt <[EMAIL PROTECTED]> wrote: > When a header has been set using header('Foo: bar') it can be replaced with > another value, but it cannot be removed. Hah! Hit that one last Friday too, gosh that was annoying! > I suggest extending the behaviour of he