Re: [PHP-DEV] E_USER_DEPRECATED
On 18.07.2008, at 23:29, Lars Strojny wrote: Hello, I've create a patch to introduce E_USER_DEPRECATED for user level deprecation warnings. I think the purpose is fairly obvious and it corresponds with the rest of our user level errors (E_USER_ERROR, E_USER_WARNING). 5_3: http://lars.schokokeks.org/php/E_USER_DEPRECATED.diff HEAD: http://lars.schokokeks.org/php/E_USER_DEPRECATED-HEAD.diff Can someone with ZE karma commit this for Lars? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_USER_DEPRECATED
On Mon, Jul 21, 2008 at 10:14, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: On 18.07.2008, at 23:29, Lars Strojny wrote: Hello, I've create a patch to introduce E_USER_DEPRECATED for user level deprecation warnings. I think the purpose is fairly obvious and it corresponds with the rest of our user level errors (E_USER_ERROR, E_USER_WARNING). 5_3: http://lars.schokokeks.org/php/E_USER_DEPRECATED.diff HEAD: http://lars.schokokeks.org/php/E_USER_DEPRECATED-HEAD.diff Can someone with ZE karma commit this for Lars? Done. As a co-RM, shouldn't you have ZE karma? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (65 total -- which includes 26 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[*Regular Expressions]= 44923 Open ereg works differently in PHP 6.0 unicode.semantics=on ===[*Unicode Issues]== 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib ouptut compression is on ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy 44043 Open Enforcing a method without specifying the arguments ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 45246 Open make error after ./configure --with-mysql ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[MySQL related] 44076 Open mysql_result returns nothing with blob ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash ===[Scripting Engine problem]= 33487 Assigned Memory allocated for objects created in object methods is not released 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe ===[Session related]== 44860 Open session_encode fails for php_binary serialiser ===[Strings related]== 44075 Verified strtok misbehaving 45566 Open Strict comparision on $_SERVER values fail ===[Unicode Engine related]=== 45248 Open Shfift_JIS encoded characters in PHP script cause an error. ===[Unknown/Other Function]=== 45087 Open Illegal or truncated character in input ===[XML related]== 45022 Open Can't get php6 snap to ./configure on mac, fails at libxml2 ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase ===[Zlib Related]= 30153 Suspended FATAL erealloc() error when using gzinflate() Assigned bugs and feature requests
[PHP-DEV] Patch for #41996
Attached is a patch plus test case for PHP_5_3's PDO_OCI that fixes
bug #41996. Should cleanly apply to HEAD, too.
Martin
Index: oci_statement.c
===
RCS file: /repository/php-src/ext/pdo_oci/oci_statement.c,v
retrieving revision 1.25
diff -u -r1.25 oci_statement.c
--- oci_statement.c 31 Dec 2007 07:12:13 - 1.25
+++ oci_statement.c 21 Jul 2008 10:16:31 -
@@ -415,7 +415,7 @@
case SQLT_BIN:
default:
dyn = FALSE;
- if (dtype == SQLT_DAT || dtype == SQLT_NUM
+ if (dtype == SQLT_DAT || dtype == SQLT_NUM || dtype == SQLT_RDD
#ifdef SQLT_TIMESTAMP
|| dtype == SQLT_TIMESTAMP
#endif
Index: tests/bug_41996.phpt
===
RCS file: tests/bug_41996.phpt
diff -N tests/bug_41996.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ tests/bug_41996.phpt 21 Jul 2008 10:16:31 -
@@ -0,0 +1,19 @@
+--TEST--
+PDO OCI Bug #41996 (Problem accessing Oracle ROWID)
+--SKIPIF--
+?php
+if (!extension_loaded('pdo') || !extension_loaded('pdo_oci')) die('skip not loaded');
+require dirname(__FILE__).'/../../pdo/tests/pdo_test.inc';
+PDOTest::skip();
+?
+--FILE--
+?php
+require 'ext/pdo/tests/pdo_test.inc';
+$db = PDOTest::test_factory('ext/pdo_oci/tests/common.phpt');
+
+$stmt = $db-prepare('SELECT rowid FROM dual');
+$stmt-execute();
+$row = $stmt-fetch();
+var_dump(strlen($row[0]) 0);
+--EXPECTF--
+bool(true)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_USER_DEPRECATED
2008/7/21 Hannes Magnusson [EMAIL PROTECTED] On Mon, Jul 21, 2008 at 10:14, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: On 18.07.2008, at 23:29, Lars Strojny wrote: Hello, I've create a patch to introduce E_USER_DEPRECATED for user level deprecation warnings. I think the purpose is fairly obvious and it corresponds with the rest of our user level errors (E_USER_ERROR, E_USER_WARNING). 5_3: http://lars.schokokeks.org/php/E_USER_DEPRECATED.diff HEAD: http://lars.schokokeks.org/php/E_USER_DEPRECATED-HEAD.diff Can someone with ZE karma commit this for Lars? Done. As a co-RM, shouldn't you have ZE karma? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I've got the docs ready as soon as 5.3 and HEAD are committed. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants!
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Hi, ucfirst() isn't solving a pain point either. But we use it all the time (I do at least). I'm particularly for begins/endswith() function as I do this all over my code and I'd appreciate the simplification and free extra performance. Regards, Stan Vassilev I agree that many existing functions can be implemented with a combination of others, but in this case it is really just one call. The strlen() call is almost free, and in many cases you wouldn't even use it. If you are looking for .php files, for example: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php')) I just don't see that this is solving any real painpoint. -Rasmus Stan Vassilev | FM wrote: Hi, Actually starts with and ends with is a very common case. I see your concerns, but I can see instantly quite a lot of places in my code where I'd use those. And I bet it'll be faster too. Many of the string functions can be replicated with one-liners using other string functions, same for array functions. I still think a very common case should be addressed natively. Regards, Stan Vassilev For the start of the string: substr($haystack,0,strlen($needle)) == $needle And for the end of the string: substr($haystack,-strlen($needle)) == $needle For case-insensitivity, just strtolower both. Writing built-in functions for something that can be done with trivial one-liners isn't something we typically do. -Rasmus Lars Strojny wrote: Hi Martin, first of all, thanks for you work! A few comments below. Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen: Attached you'll find a patch against PHP_5_3 that implements two new string functions: str_startswith(haystack, needle [, case_sensitivity]) That's in my opinion too easy to solve with strpos($haystack, $needle) === 0. checks if haystack starts with needle. The check is performed case-insensitively, but this can be overridden by passing TRUE as the value for the third parameter. The second function str_endswith(haystack, needle [, case_sensitivity]) [...] Suffix checking is indeed a bit harder. But I'm not sure if we should introduce a function for every special case. Suffix verification often is about verifying file extensions. That could be easily solved with pathinfo() (and to make that easier, it would be more helpful to allow the engine to directly access returned arrays like pathinfo($file)['extension']). The other thing I would love to see is something I really love in Ruby: you have various ways to work with substrings[1]. For example you can do foobar[-3,3] == bar to check the suffix. That's in my opinion much easier and flexible. So -1 from me for the new string functions, but +1 for niftier variants to work with offsets. [1] http://pleac.sourceforge.net/pleac_ruby/strings.html cu, Lars -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Surely substr_compare() does both begin end easily enough. Though the fact that it throws warnings is annoying. Jared -Original Message- From: Stan Vassilev | FM [mailto:[EMAIL PROTECTED] Sent: 21 July 2008 13:18 To: internals Subject: Re: [PHP-DEV] New string functions: str_startswith() and str_endswith() Hi, ucfirst() isn't solving a pain point either. But we use it all the time (I do at least). I'm particularly for begins/endswith() function as I do this all over my code and I'd appreciate the simplification and free extra performance. Regards, Stan Vassilev I agree that many existing functions can be implemented with a combination of others, but in this case it is really just one call. The strlen() call is almost free, and in many cases you wouldn't even use it. If you are looking for .php files, for example: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php')) I just don't see that this is solving any real painpoint. -Rasmus Stan Vassilev | FM wrote: Hi, Actually starts with and ends with is a very common case. I see your concerns, but I can see instantly quite a lot of places in my code where I'd use those. And I bet it'll be faster too. Many of the string functions can be replicated with one-liners using other string functions, same for array functions. I still think a very common case should be addressed natively. Regards, Stan Vassilev For the start of the string: substr($haystack,0,strlen($needle)) == $needle And for the end of the string: substr($haystack,-strlen($needle)) == $needle For case-insensitivity, just strtolower both. Writing built-in functions for something that can be done with trivial one-liners isn't something we typically do. -Rasmus Lars Strojny wrote: Hi Martin, first of all, thanks for you work! A few comments below. Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen: Attached you'll find a patch against PHP_5_3 that implements two new string functions: str_startswith(haystack, needle [, case_sensitivity]) That's in my opinion too easy to solve with strpos($haystack, $needle) === 0. checks if haystack starts with needle. The check is performed case-insensitively, but this can be overridden by passing TRUE as the value for the third parameter. The second function str_endswith(haystack, needle [, case_sensitivity]) [...] Suffix checking is indeed a bit harder. But I'm not sure if we should introduce a function for every special case. Suffix verification often is about verifying file extensions. That could be easily solved with pathinfo() (and to make that easier, it would be more helpful to allow the engine to directly access returned arrays like pathinfo($file)['extension']). The other thing I would love to see is something I really love in Ruby: you have various ways to work with substrings[1]. For example you can do foobar[-3,3] == bar to check the suffix. That's in my opinion much easier and flexible. So -1 from me for the new string functions, but +1 for niftier variants to work with offsets. [1] http://pleac.sourceforge.net/pleac_ruby/strings.html cu, Lars -- 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 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] New string functions: str_startswith() and str_endswith()
Stan Vassilev | FM wrote: I'm particularly for begins/endswith() function as I do this all over my code and I'd appreciate the simplification and free extra performance. I really don't mean to be rude here, but shorter and less typing !== performance gain. The PHP string functions are very fast. And if you are looking to improve your applications performance by using different string functions, you are likely looking in the wrong place. -- Brian Moon Senior Web Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_inline_hash_function reimplementation
On 21.07.2008, at 17:29, Michal Dziemianko wrote: Hello, I have looked into Zend/zend_hash.h and I guess it might be sped up a little. So far it uses D. Bernstein's hash which is quite fast, but I think it might be worth replacing it with MurmurHash. I have tried comparison of speed for them (both as separate C programs, and compiled into PHP 5_3). Results for REAL keys (collected on running web server) are at the bottom of this page: http://212.85.117.53/gsoc/index.php?option=com_contentview=articleid=65:hash-functions-for-hash-tablescatid=34:profilingItemid=54 speeding up array's does indeed look like a place where one could give a nice boost to many php applications. however it is also a place that could create such as many problems of course. so getting this into 5.3 seems a bit unlikely at this point given that the feature freeze is planned for the 24th. that being said, on the page i only see benchmarks with artificial data/code. did you also run some benchmarks again some popular php applications so see what the real world benefits are in terms of requests per second? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Brian Moon wrote: Stan Vassilev | FM wrote: I'm particularly for begins/endswith() function as I do this all over my code and I'd appreciate the simplification and free extra performance. I really don't mean to be rude here, but shorter and less typing !== performance gain. The PHP string functions are very fast. And if you are looking to improve your applications performance by using different string functions, you are likely looking in the wrong place. It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') And there would be no performance gain since it can be done in a single call now and the code would do pretty much exactly what substr does. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / run-tests.php
Please reply via the mailing list. You did weird ws changes in HEAD but not in 5.3 and vise-versa. That's VERY bad thing considering this script must be SAME for both branches. If you can't keep it in sync, don't touch it. Otherwise the bunnies get it.. Feel free to commit the help texts. I'm done with it. --Jani Steph Fox wrote: Like lot of other weird changes. Um, not really no :) There's only run-tests and info.c I've touched outside /win32 and /ext/phar. This file is supposed to be identical in PHP_5_3 and HEAD from now on. DO NOT TOUCH it before I've done my magic on it.. I was about to commit those help messages. Did you want me to leave those 'til you're done too? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #41996
hi Martin! On Mon, Jul 21, 2008 at 12:18 PM, Martin Jansen [EMAIL PROTECTED] wrote: Attached is a patch plus test case for PHP_5_3's PDO_OCI that fixes bug #41996. Should cleanly apply to HEAD, too. Applied to HEAD and 5.3, thanks for your work! Cheers, -- Pierre 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] Patch for #41996
On Mon, Jul 21, 2008 at 7:36 PM, Pierre Joye [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 12:18 PM, Martin Jansen [EMAIL PROTECTED] wrote: Attached is a patch plus test case for PHP_5_3's PDO_OCI that fixes bug #41996. Should cleanly apply to HEAD, too. Applied to HEAD and 5.3, thanks for your work! Great, thanks. Can you also look into my patch for #44301 which I sent in yesterday? Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] zend_inline_hash_function reimplementation
Hi Michal, Can you please send a link to the patch so we can review? I didn't get the attachment. Thanks, Andi -Original Message- From: Michal Dziemianko [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 8:29 AM To: internals@lists.php.net Subject: [PHP-DEV] zend_inline_hash_function reimplementation Hello, I have looked into Zend/zend_hash.h and I guess it might be sped up a little. So far it uses D. Bernstein's hash which is quite fast, but I think it might be worth replacing it with MurmurHash. I have tried comparison of speed for them (both as separate C programs, and compiled into PHP 5_3). Results for REAL keys (collected on running web server) are at the bottom of this page: http://212.85.117.53/gsoc/ index.php?option=com_contentview=articleid=65:hash-functions-for- hash-tablescatid=34:profilingItemid=54 Murmur is Public Domain, and its author is maintaining it all the time so I guess it will be faster and better. There is comparison of distribution at both the page I gave and here: http:// murmurhash.googlepages.com/ The patch for 5_3 (applicable to HEAD) as attachment -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for #41996
hi! On Mon, Jul 21, 2008 at 7:52 PM, Martin Jansen [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 7:36 PM, Pierre Joye [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 12:18 PM, Martin Jansen [EMAIL PROTECTED] wrote: Attached is a patch plus test case for PHP_5_3's PDO_OCI that fixes bug #41996. Should cleanly apply to HEAD, too. Applied to HEAD and 5.3, thanks for your work! Great, thanks. Can you also look into my patch for #44301 which I sent in yesterday? Yes, I will do it later tonight :) Cheers, -- Pierre 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] zend_inline_hash_function reimplementation
Hi Andi,
The patch is attached for 5_3.
I've got some time allocated tomorrow to review all of Michal's patches
that have been produced for the GSoC. I'll try to post some figures from
real life apps.
Scott
Andi Gutmans wrote:
Hi Michal,
Can you please send a link to the patch so we can review? I didn't get
the attachment.
Thanks,
Andi
-Original Message-
From: Michal Dziemianko [mailto:[EMAIL PROTECTED]
Sent: Monday, July 21, 2008 8:29 AM
To: internals@lists.php.net
Subject: [PHP-DEV] zend_inline_hash_function reimplementation
Hello,
I have looked into Zend/zend_hash.h and I guess it might be sped up a
little.
So far it uses D. Bernstein's hash which is quite fast, but I think it
might
be worth replacing it with MurmurHash. I have tried comparison of
speed for
them (both as separate C programs, and compiled into PHP 5_3). Results
for
REAL keys (collected on running web server) are at the bottom of this
page:
http://212.85.117.53/gsoc/
index.php?option=com_contentview=articleid=65:hash-functions-for-
hash-tablescatid=34:profilingItemid=54
Murmur is Public Domain, and its author is maintaining it all the time
so I
guess it will be faster and better. There is comparison of
distribution at
both the page I gave and here: http:// murmurhash.googlepages.com/
The patch for 5_3 (applicable to HEAD) as attachment
Index: zend_hash.h
===
RCS file: /repository/ZendEngine2/zend_hash.h,v
retrieving revision 1.78.2.2.2.2.2.4
diff -u -d -r1.78.2.2.2.2.2.4 zend_hash.h
--- zend_hash.h 29 Apr 2008 08:15:17 - 1.78.2.2.2.2.2.4
+++ zend_hash.h 20 Jul 2008 12:37:41 -
@@ -222,65 +222,47 @@
ZEND_API int zend_hash_rehash(HashTable *ht);
/*
- * DJBX33A (Daniel J. Bernstein, Times 33 with Addition)
- *
- * This is Daniel J. Bernstein's popular `times 33' hash function as
- * posted by him years ago on comp.lang.c. It basically uses a function
- * like ``hash(i) = hash(i-1) * 33 + str[i]''. This is one of the best
- * known hash functions for strings. Because it is both computed very
- * fast and distributes very well.
- *
- * The magic of number 33, i.e. why it works better than many other
- * constants, prime or not, has never been adequately explained by
- * anyone. So I try an explanation: if one experimentally tests all
- * multipliers between 1 and 256 (as RSE did now) one detects that even
- * numbers are not useable at all. The remaining 128 odd numbers
- * (except for the number 1) work more or less all equally well. They
- * all distribute in an acceptable way and this way fill a hash table
- * with an average percent of approx. 86%.
- *
- * If one compares the Chi^2 values of the variants, the number 33 not
- * even has the best value. But the number 33 and a few other equally
- * good numbers like 17, 31, 63, 127 and 129 have nevertheless a great
- * advantage to the remaining numbers in the large set of possible
- * multipliers: their multiply operation can be replaced by a faster
- * operation based on just one shift plus either a single addition
- * or subtraction operation. And because a hash function has to both
- * distribute good _and_ has to be very fast to compute, those few
- * numbers should be preferred and seems to be the reason why Daniel J.
- * Bernstein also preferred it.
- *
- *
- * -- Ralf S. Engelschall [EMAIL PROTECTED]
+ * MURMUR Hash - http://murmurhash.googlepages.com/
*/
-
-static inline ulong zend_inline_hash_func(const char *arKey, uint nKeyLength)
+#define MURMUR_SEED 5831
+#define MURMUR_M 0x5bd1e995
+#define MURMUR_R 24
+static inline ulong zend_inline_hash_func(const char *key, uint len)
{
- register ulong hash = 5381;
+ unsigned int h = MURMUR_SEED ^ len;
+ unsigned char * data = (unsigned char *)key;
- /* variant with the hash unrolled eight times */
- for (; nKeyLength = 8; nKeyLength -= 8) {
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- hash = ((hash 5) + hash) + *arKey++;
- }
- switch (nKeyLength) {
- case 7: hash = ((hash 5) + hash) + *arKey++; /*
fallthrough... */
- case 6: hash = ((hash 5) + hash) + *arKey++; /*
fallthrough... */
- case 5: hash = ((hash 5) + hash) + *arKey++; /*
fallthrough... */
- case 4: hash = ((hash 5) + hash) + *arKey++; /*
fallthrough... */
- case 3: hash = ((hash 5) + hash) + *arKey++; /*
fallthrough... */
- case 2: hash = ((hash 5) + hash) + *arKey++; /*
fallthrough... */
- case 1: hash = ((hash 5) + hash) + *arKey++;
[PHP-DEV] Rounding in PHP and floating point numbers in general
Hi, With this posting I'd like to make another try in resolving the rounding issues in PHP. This is basically in response to http://bugs.php.net/bug.php?id=42294 (bug #42294) where I added a comment last year. Since then I have read quite a bit on this subject so I feel that I should post an update to my previous comment (which isn't completely correct, as are some other things I reference in this mail, please keep that in mind while reading them). And since the bug seems to have been forgotten, I think I should try this on the mailing list. A) General explanations === Rounding methods: - Round to negative infinity: Should be obvious, some examples: -0.5 - -1 0.5 - 0 2.4 - 2 -3.6 - -4 4.8 - 4 This is what the floor() function does. - Round to positive infinity: Obvious, some examples: -0.5 - 0 [actually, -0] 0.5 - 1 2.4 - 3 -3.6 - -3 4.8 - 5 This is what the ceil() function does. - Round to zero: Some examples: -0.5 - 0 [actually, -0] 0.5 - 0 2.4 - 2 -3.6 - -3 4.8 - 4 - Round away from zero: Some examples: -0.5 - -1 0.5 - 1 2.4 - 3 -3.6 - -4 4.8 - 5 - Round no nearest: Rounds to nearest integer. Examples not involving .5: 2.4 - 2 -3.2 - -3 -3.6 - -4 4.8 - 5 2.501 - 3 -2.501 - -3 [Note the last two examples: they are not exactly .5 so they do not have the equal distance from both integers so the rounding direction in this case is clear.] There are four main variants of this rounding method regarding the treatment of .5 (which is exactly in the middle of two integers): * Away from zero: .5 will always be rounded to the next integer away from zero: -1.5 - -2 1.5 - 2 -2.5 - -3 2.5 - 3 This is the traditional arithmetic rounding people learn in school. * Towards zero: .5 will always be rounded to the next integer towards zero: -1.5 - -1 1.5 - 1 -2.5 - -2 2.5 - 2 * Towards even: .5 will always be rounded to the next even integer: -1.5 - -2 1.5 - 2 -2.5 - -2 2.5 - 2 This is the so-called banker's rouding. * Towards odd: .5 will always be rounded to the next odd integer: -1.5 - -1 1.5 - 1 -2.5 - -3 2.5 - 3 In practice, only round to negative/positive infinity (floor/ceil), arithmetic rounding (round to nearest, away from zero) and banker's rouding (round to nearest, towards odd) are widely used. B) Rounding occurs in = There are various places in PHP where rounding (explicit or implicit) occurs: Explicitely: * round() * number_format() * (sf)printf() with %3f etc. Implicitely: * float to string conversion (the 'precision' ini setting) * (sf)printf() with %g The problem is that different methods are used for this rounding. C) History of the round() function in PHP = First version in CVS (math.c): - No precision argument, always rounds to integer - Use rint() for rounding ISO C says: rint() uses the current rounding direction which on every machine known to me is round to even (so-called banker's rounding). But: Rounding direction may be changed by fesetround()! - On systems where rint() is not specified, rint() is emulated. But the emulation is done via an algorithm that does arithmetic rounding. Version 1.22 (May 17, 2000): - Allow arbitrary precision rounding, now implement an algorithm that does arithmetic rounding. Version 1.104 (Aug 8, 2003): - Add fuzz due to incorrect results (see below) Version 1.106 (Aug 9, 2003): - Disable fuzz on Win32, make (useless) configure check on UNIX July 23, 2004: (Slightly flawed) analysis of the FP and rounding situation in PHP and proposal to fix that on the internals mailinglist: http://marc.info/?l=php-internalsm=109057070829170w=2 The linked C files are still available through the wayback machine via http://web.archive.org/ to get an impression what George actually meant. D) Problem analysis === In this section I want to provide an analysis of the problems that occur with PHPs rounding functionality. First of all, rounding to integer is never a problem as long as the number of digits before the decimal point is smaller than the floating point precision. But does anyone really want to round something to 15 significant (!) digits precision and still use floats? I believe not. So, if you want to do
RE: [PHP-DEV] zend_inline_hash_function reimplementation
Thanks. Is there also a 64bit variant of this algorithm? That could deliver a substantial benefit. Andi -Original Message- From: Scott MacVicar [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 11:15 AM To: Andi Gutmans Cc: Michal Dziemianko; internals@lists.php.net Subject: Re: [PHP-DEV] zend_inline_hash_function reimplementation Hi Andi, The patch is attached for 5_3. I've got some time allocated tomorrow to review all of Michal's patches that have been produced for the GSoC. I'll try to post some figures from real life apps. Scott Andi Gutmans wrote: Hi Michal, Can you please send a link to the patch so we can review? I didn't get the attachment. Thanks, Andi -Original Message- From: Michal Dziemianko [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 8:29 AM To: internals@lists.php.net Subject: [PHP-DEV] zend_inline_hash_function reimplementation Hello, I have looked into Zend/zend_hash.h and I guess it might be sped up a little. So far it uses D. Bernstein's hash which is quite fast, but I think it might be worth replacing it with MurmurHash. I have tried comparison of speed for them (both as separate C programs, and compiled into PHP 5_3). Results for REAL keys (collected on running web server) are at the bottom of this page: http://212.85.117.53/gsoc/ index.php?option=com_contentview=articleid=65:hash-functions-for- hash-tablescatid=34:profilingItemid=54 Murmur is Public Domain, and its author is maintaining it all the time so I guess it will be faster and better. There is comparison of distribution at both the page I gave and here: http:// murmurhash.googlepages.com/ The patch for 5_3 (applicable to HEAD) as attachment -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Hi! It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') Doesn't substr allocate new string for .php? Then endswith can have one advantage of not requiring any new allocations. Not sure it's enough to add it, but a point here to consider. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Hello All, I had a chat with Etienne and Stas on IRC to try and figure out how to approach things. We decided that its best to go with only having parent:: be forwarding for alpha1. Depending on user feedback we might revisit the topic, but for now it seems that with this solution the limitations (and all 3 approaches - never, always and parent only forwarding - have limitations where they do not do what a user might need) are apparent less often and can usually be dealt with towards the base of the inheritance tree (which means it will be less of an issue in day to day programming). Etienne will handle applying the patch and doing at least a base line summary of the decision process, so that we have this as a reference if we ever revisit the topic. I hope that everybody can live with this decision. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
On 17.07.2008, at 20:03, Stanislav Malyshev wrote: Hi! Greg's argument seems sound to me. With the proposed change errors are less likely and more transparent in case they happen (for people using No, they won't be transparent at all. If you use Exception and forget to put use ::Exception in each and every of your files, you get exhaustive search of include path (not helped by bytecode caching, btw - all bytecode caches I know cache existing files, not searches for non-existing ones) on each mention of Exception. You can not see it - on the surface, everything works fine. Then, when you think your code is fine, you run profiler and boom - you see 200 file accesses where there should be none. autoload that is). At the same time people who care about performance can still work around this behavior (then again those that care about optimizations on this level probably do not use autload to begin with). What's wrong with autoload? You sound like autoload is somehow contrary to performance, which is not true. So I guess the point is .. autoload is there for convinience, so lets make it as convinient as possible. I don't see how having internal class mention trigger exhaustive autoload search is as convenient as possible. For me, it is a huge landmine under every PHP application trying to use namespaces - forget one use statement and boom, your performance is gone. If you want to do that, you better force using ::Class everywhere - this way at least there's a way to know where it will blow up without running system call traces on every piece of code. For this issue it seems like there is nobody that has enough inertia to change the current status quo. As such it seems to me like we should go to alpha1 as is. I hope that namespaces have enough buzz that we quickly get feedback after alpha1. We should do as much encouragement to get people to test namespaces as possible. At the moment namespaces is probably the feature that makes me most nervous. Followed by GC and the re2c change. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008: It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') Only if comparing to a static string, but not for this case: if (substr($path, -strlen($extension)) == $extension) Readability would also increase. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Paweł Stradomski kirjoitti: W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008: It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') Only if comparing to a static string, but not for this case: if (substr($path, -strlen($extension)) == $extension) Readability would also increase. You people are funny.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests rename_dir.phpt rmdir.phpt /ext/phar/tests/tar rename_dir.phpt rmdir.phpt /ext/phar/tests/zip rename_dir.phpt rmdir.phpt
On 17.07.2008, at 04:17, Greg Beaver wrote: Dmitry Stogov wrote: dmitry Thu Jul 10 14:27:21 2008 UTC Added files: (Branch: PHP_5_3) /php-src/ext/phar/tests rename_dir.phpt rmdir.phpt /php-src/ ext/phar/tests/tar rename_dir.phpt rmdir.phpt /php-src/ext/phar/ tests/zip rename_dir.phpt rmdir.phpt Log: Added tests that demonstrate serious PHAR errors They cannot be easly fixed without algorithms modification Hi Dmitry, These tests all demonstrate modification of virtual directories, i.e. directories that are not really in the archive as entries, but simply are part of a path of existing files. However, I think we can easily add support for this by adding an iteration loop at the end of phar_wrapper_rename and phar_wrapper_rmdir implementations that cycles over all of the files and renames their directories. It would be slow, but truth be told, this is only going to be done on phar construction anyways, so performance is not a huge issue there. There is a similar loop that can be cut/pasted from phar_make_dirstream in phar/dirstream.c that scans all files to find matches that are in the requested directory. With slight modification to the loop the tests will pass (i.e. instead of adding the file to the opendir hash, perform the rename of the directory portion of the filename using a clever spprintf and a few temporary null bytes at directory separator boundaries in the original file, then zend_hash_add a new entry and either remove the old one or mark it deleted if it has open refcounts). The rmdir implementation should simply fail if any file or directory exists in the virtual directory. If no one fixes this by August 13 or so, I will try my hand at it. I would be great to have this fixed for alpha1, but if no one has time I guess it will have to wait for alpha2. Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
On 17.07.2008, at 16:20, Matt Wilmas wrote: Hi all, Replying to this OLD message about the ZEND_SIGNED_MULTIPLY_LONG() change... It's just a small thing, but it's been on the TODO for a while, so I attempted to correct the issue with my original patch that used long long type, which wasn't available on the older MSVC versions, etc. I created a zend_long64 type (when possible, #if logic copied from snprintf.h's WIDE_INT definition), hopefully it's mostly correct/OK, and maybe it can be used elsewhere too. Since the new memory manager, ..._MULTIPLY_LONG() isn't used for safe_emalloc() anymore, so I made another safe_address() variation (overflow safe, I hope). I noticed ~0.6% slowdown on bench.php, though it seems this zend_ulong64 version should use fewer cycles than the doubles one for sure, if someone wants to analyze it more. :-) Finally, is it even possible to also have a Windows assembly version of these 2 things, where I left the comments? There is for zend_mm_[high|low]_bit(), but they're very simple... http://realplain.com/php/multiply_long.diff http://realplain.com/php/multiply_long_5_3.diff any takers for this patch? otherwise it will probably not make the cut by the 24th regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Jani Taskinen wrote:
Paweł Stradomski kirjoitti:
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008:
It also isn't any shorter:
if(str_endswith($path,'.php'))
vs.
if(substr($path,-4)=='.php')
Only if comparing to a static string, but not for this case:
if (substr($path, -strlen($extension)) == $extension)
Readability would also increase.
You people are funny..
I'd like to have such a function in PHP, but when you think about how
easy it is to create without bloating the PHP core, it's easy enough to
do without it. Here's what I do using my own string library:
if (LS_Util_String :: ends_with($path, '.php')) {
...
}
It's a bit longer, but all my functions are longer for good reason:
http://www.dantescode.com/2007/10/10/evolution-of-php-coder-naming-classes/
-- Dante
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
On 18.07.2008, at 10:11, Pierre Joye wrote: On Fri, Jul 18, 2008 at 9:27 AM, Ulf Wendel [EMAIL PROTECTED] wrote: Lester Caine schrieb: Ulf Wendel wrote: If mysqlnd turns out to be stable enough during the PHP 5.3 test phase, PHP 5.3+ may use mysqlnd as a default. There is no need to download an extra library when using 5.3. Lukas, this is not affecting PHP 5.3 as long as mysqlnd is stable/fast/... enough to be used as a default. BUT - does mysqlnd produce data in phpinfo() ? So when loaded by default you confuse end users when looking for problems on systems that do not use MySQL. We discussed that earlier in the thread: there's no need to load mysqlnd if there's no mysql extension loaded and using it - BUG, though not a high priority one. Just like there is no need to load ext/pdo when no pdo driver gets loaded. The question is also how much sense it makes. The main problem is the dependency loading mechanism, which does not exist. That's the main why PDO and MySqlnd can't be compiled as shared (or should not). If I configure PHP without any mysql extension, does that mean that I will never add one? I'm not sure but if we disable PDO and mysqlnd when no driver are enabled at compile time, it means that I will have to recompile PHP as soon as I like to use a pdo or mysqlnd driver. I will let the RM decides :-D It seems to me like in 99% of the cases on linux the initial install of PHP will include PDO and MySQL (ok lets say 90% for MySQL and 99% for PDO) intentionally anyways. For the rest they will be hand compiling anyways on Linux. I guess this leaves the only issue being the order in which the extensions get listed in the php.ini, right? There I guess we should just try to provide a good error message, but if we can't then the error message will likely soon plaster google/ yahoo with solutions (ideally our manual would be at the top). For windows I feel that its mainly used for development, as such I would rather want to see things compiled in to reduce trouble, especially for novice users. For those users looking to get super stream lined binaries, with the work by the windows team its more feasible than ever to make your own binaries (or have someone else do it for them). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_inline_hash_function reimplementation
Hi! I understand this patch has potential portability issues for architectures that won't be able to read int's unaligned. Maybe we could keep both of them and do some configure test to see if it works fine, if not - use the old one? Also I understand that this function returns uint while old hash returned ulong. What happens with that on 64-bit platforms? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously
On 18.07.2008, at 01:23, Moriyoshi Koizumi wrote: Hi, Attached are the patches that allow the use statement that was introduced with closures to appear within every function statement except method definitions. I think this feature is a good addition because it resolves inconsistency between closures and unticked functions. In a nutshell, I talked to Johannes, given that the thread has not garned much attention (maybe with this reply this will change) and the fact that since quite some time we have instead tried to encourage people to leverage $GLOBALS instead, it does not seem like we need to squeeze this new syntax into 5.3 so shortly before the feature freeze (I guess you get what you deserve by allowing closures in so late before the feature freeze?). If we get feedback that end users that are new to PHP feel like they expect this syntax when they are exposed to closures we might want to add this in 5.4/6.0? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c
Hi Lukas, On Mon, Jul 21, 2008 at 10:52 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: It seems to me like in 99% of the cases on linux the initial install of PHP will include PDO and MySQL (ok lets say 90% for MySQL and 99% for PDO) intentionally anyways. For the rest they will be hand compiling anyways on Linux. I guess this leaves the only issue being the order in which the extensions get listed in the php.ini, right? Yes, and dependencies detection at load/run time is not yet ready. It may be possible on windows (not for 5.3) later though. There I guess we should just try to provide a good error message, but if we can't then the error message will likely soon plaster google/yahoo with solutions (ideally our manual would be at the top). For windows I feel that its mainly used for development, as such I would rather want to see things compiled in to reduce trouble, especially for novice users. For those users looking to get super stream lined binaries, with the work by the windows team its more feasible than ever to make your own binaries (or have someone else do it for them). It is easy, but it is not possible yet to disable mysqlnd, but it is possible already to disable PDO. Cheers, -- Pierre 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] New string functions: str_startswith() and str_endswith()
On Mon, 2008-07-21 at 22:06 +0200, Paweł Stradomski wrote: W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008: It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') Only if comparing to a static string, but not for this case: if (substr($path, -strlen($extension)) == $extension) Then $extension is a CV which isn't that much slower in comparison as a CONST, so from engine-performance-perspective: no big deal - spend your time optimizing on other places where it has more effect than the time you loose on teaching people about all the fancy string functions (where we already have more than enough) Readability would also increase. too many functions hurt more on readability imo ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_inline_hash_function reimplementation
There is an aligned version of the algorithm available but its slower, there is also a 64-bit version in the works. I emailed the author about its progress to check. At the moment adding both looks the way forward, i'll benchmark a PPC version of the algorithm shortly. Scott On 21 Jul 2008, at 21:58, Stanislav Malyshev wrote: Hi! I understand this patch has potential portability issues for architectures that won't be able to read int's unaligned. Maybe we could keep both of them and do some configure test to see if it works fine, if not - use the old one? Also I understand that this function returns uint while old hash returned ulong. What happens with that on 64-bit platforms? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Hello, On Mon, Jul 21, 2008 at 9:48 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Etienne will handle applying the patch and doing at least a base line summary of the decision process, so that we have this as a reference if we ever revisit the topic. I can't apply the patch, as it requires ZE2 karma which I don't have. I'll write a RFC for it though. Regards, -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: parent:: forwarding
Hi! I can't apply the patch, as it requires ZE2 karma which I don't have. I'll write a RFC for it though. Please add there a link to the newest patch, since there was a lot of variations around... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Modify language grammar to allow trailing commas in function/method calls
This was floated in 2003 but had weak advocation and didn't seem to come to a decisive resolution: http://marc.info/?l=php-internalsm=106685833011253w=2 Basically, the proposal is to modify the grammar to allow trailing commas in function and method calls, so this becomes a parseable PHP construct: f(1, 2, 3,); This patch applies only to function and method calls; it does not apply to function or method definitions. It also does not allow the degenerative case of f(,). The real value of relaxing this rule is in nontrivial cases that span across multiple lines: sprintf( 'long example pattern with %d conversions: %s', $several, $conversions ); This sort of construction makes the code more readable but also exposes you to trailing-comma errors. You can easily introduce an error either by removing the last parameter or by changing parameter order. At least in my experience, these are relatively common syntax errors, and ones that are easy to make when making edits that are apparently minor. In the above example, I can remove the %s conversion, remove the $conversions parameter, and inadvertently introduce a syntax error because I have neglected to remove the comma after $several. Similarly, I can change the parameter order by modifying the string and swapping $several for $conversions, but introduce a syntax error by neglecting to move the comma. In the current grammar, if a function or method call has been written with parameters broken across multiple lines, adding or removing a trailing parameter means you need to modify two lines of code instead of one. This muddies and reduces the value of blame features in revision control. It also makes diffs slightly larger and noisier, which can make code reviews take a little longer since you have to scan the line and make sure the only change is to the trailing comma. The looser grammar is easier to use and more consistent: it's easier to add, remove, or move parameters in an editor since you only need to use line-oriented editor operations, and you don't need to mentally distinguish between an array context and a parameter context. In the original thread, Andi Gutmans explained that the decision to allowing trailing commas in array() literals is supported by the argument that it makes code generation easier. It seems like this argument applies to trailing commas in function definitions just as easily, and that the general ease-of-use arguments laid out above provide at least as much value as this (particularly since this specific code generation problem is solvable with implode()). Andi also argued that this reduces readability and prevents assigning semantics to a trailing comma in the future. While I agree that it reduces readability in the f(1, 2,) case, I disagree that it reduces readability in the less trivial multi-line case and it greatly enhances writeability. The possibility that the language would ever benefit from assigning semantics here, while worth considering, seems small. While my language architect credentials are pretty weak, I can't think of any reasonable meaning. Many languages accept trailing commas in data definitions (apparently including Java (!) now[1]), and some (such as Python[2]) accept them in calls; in all cases, the behavior is to ignore them. If PHP provided a different semantic, this would be somewhat startling. In general, trailing commas are increasingly an accepted part of the grammars of modern languages. Beyond Java, Ruby and Python, Firefox now accepts them in Javascript object definitions (which is surefire way to tell that someone didn't test in IE). While they are more often accepted in data definitions than calls, I don't see a strong reason to distinguish between the cases. This change has no impact on backward compatibility. It does makes it slightly more difficult to write code which runs across multiple versions of PHP. However, because it fails fast and explicitly, it's an error which is easy to detect and resolve when you decide you want to support more versions of PHP with your project. It's also straightforward to write a script that uses the tokenizer to safely and unambiguously remove trailing commas (I'd be happy to furnish such a script if people think there's value in it and there's a reasonable place to put it). The diff in the original thread still seems correct, at least against a relatively recent release -- I applied it to PHP 5.2.5 and ran the tests, as well as verifying that the build could parse and execute code which used trailing commas in calls. So, what's the feeling on this? We're trying to weigh the merits of rolling it into our stack at Facebook, but we'd feel a lot more comfortable if it was present upstream. Thanks, Evan Priestley [1]
