[PHP-DEV] PHP 5 Bug Summary Report
PHP 5 Bug Database summary - http://bugs.php.net/ Num Status Summary (1560 total -- which includes 1016 feature requests) ===[*Directory/Filesystem functions] 49620 Suspended is_writeable does not work using netshare and normal user rights 50542 Assigned scandir() cannot open UNC paths since PHP 5.3.1 ===[*General Issues]== 48597 Open Unclosed array keys break space escaping in $_GET/POST/REQUEST 50314 Verified File upload problem with typo in form 50512 Open Yuml is missing in HTML translation table 50531 Feedback CLI script stops at fatal error: Maximum execution time of 200 seconds exceeded ===[*Programming Data Structures]= 50586 Feedback Greater than operator '' causes script to drop out of PHP into HTML ===[*Unicode Issues]== 49687 Assigned utf8_decode xml_utf8_decode vuln ===[Apache related]=== 48894 Open Occasional crashes with Apache 1.3.41 ===[Apache2 related]== 32220 Assigned [PATCH] thread_resources for thread not getting freed when apache kills thread 45945 Open Apache byterange output filter nullified if mod_php5 output 8000 bytes 47681 Open System TMP dir ignored in file uploads 48260 Open Size of PHP file affects behaviour of virtual() or #include virtual 49106 Open PHP incorrectly sets no_local_copy=1 on response as Apache 2 module 49816 Assigned output corruption using flush 50203 Open Apache +mod_php can't load script with non-ASCII name 50369 Open PHP Crashing Apache on Win7x64 ===[BC math related]== 44995 Analyzed bcpowmod() should not have scale parameter (only 0 is supported) 46564 Verified bcmod( '1071', '357.5' ) returns '0' ===[Bzip2 Related] 29521 Assigned compress.bzip2 wrapper ===[Calendar related]= 40213 Suspended easter_date() returns wrong timestamp if ... ===[CGI related]== 47412 Assigned PHP_MSHUTDOWN_FUNCTION not being called under FastCGI 47605 Open CGI SAPI can not send HTTP 200 header 48831 Assigned php -i has different output to php --ini ===[Class/Object related]= 41461 Verified E_STRICT notice when overriding methods not defined by an Interface in hierarchy 46140 Open Unserializing with __wakeup that removes child causes subsequent refs to shift 46812 To be documented get_class_vars() does not include visible private variable looking at subclass 47405 Verified error reports wrong file/line 47664 Assigned get_class returns NULL instead of FALSE. 48623 Open Incorrect scope for static variables in object methods 49143 Open is_callable() and unnecessary backslash ===[COM related]== 31327 Assigned chinese char and word problem 32099 Assigned After opening ADO connection and closing it repeatedly, Apache stops service 34253 Assigned COM binary object/array issue (question marks?) 35875 Assigned IE event failure upon scheduling script 36360 Assigned PHP crashes when accessing an object that was just create by parent object 37562 Assigned Unable to lookup ParameterFieldDefinitions 37899 Assigned [PATCH] php_char_to _OLECHAR copies junk bytes 37965 Assigned Multi-dimensional array between PHP and COM 38719 Assigned COM Error during accessing function VirtualMachines 40424 Assigned Fatal error when setting the value of COM object's property array 40581 Assigned Pass Struct type to COM object from PHP 40664 Assigned String conversion functions wrong for multibyte chars 41055 Assigned DOTNET not instantiating fully-pathed assembly 41078 Assigned Its not possible to call Static dotNet Classes with dotnet 41189 Assigned Multi-dimensional array in COM function causes hang 41368 Assigned ADODB.Recordset ActiveConnection property - can't set with PHP 5.2.1+ 41388 Assigned Error in COM Object results 41577 Assigned DOTNET is successful once per server run 42413 Assigned Cannot iterate IE's event object 42551 Assigned new COM(HTMLFile) = warnings 42585 Assigned die() in event handler = PHP hangs 43275 Open get_class problem with COM objects 43432 Open Fatal error when setting the value of COM object's Attribute property 43470 Open COM API fails to correctly return [OUT] VT_PTR references 43506 Open com_get_active_object always fails 43521 Open Problem with Variant/Parameters 43838 Open variant_set with IE leads to hang 43897 Open
Re: [PHP-DEV] Proposal: allow for includes in php.ini
2009/12/23 Tjerk Meesters tjerk.meest...@gmail.com: On 24-Dec-2009, at 2:47, Pierre Joye pierre@gmail.com wrote: On Wed, Dec 23, 2009 at 7:20 PM, Michael Shadle mike...@gmail.com wrote: On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen mkoppa...@php.net wrote: Hello, I think you can use PHP_INI_SCAN_DIR environment variable which should work runtime as well. still seems a bit archaic. i don''t see any reason why include support can't be added in php.ini. it will probably wind up becoming more popular and widely used than the configure option too, or the environment option... Please tell me one benefit except we support include? I don't see any. The extra files are still there, they will be loaded too, etc. The most tempting reason for me would be to have easier control of what gets loaded between SAPI's, eg load this ini for cli but not for cgi, etc. Right now this is only possible by compiling each Sapi with its own search path, which is more cumbersome. 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 For different SAPIs ... php-cli.ini, php-isapi.ini, php-cgi-fcgi.ini, etc. is what I use on Windows. Combined with registry settings for PHP (Prior to PHP5), PHP5 and PHP6, I can very easily dictate which INI file will be loaded for which version of PHP and for which SAPI. Beyond that, I can use [HOST=] for some host specific settings. All of this is with the standard windows pre-compiled binaries. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
Pierre Joye wrote: First suggestion, would it be possible to have *.c/h first in the results instead of the phpt? I'm not sure, but I'll have a look. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
Philip Olson wrote: Looks great, and much nicer. If you feel pb11[1] could handle it, then we could dedicate this box to OpenGrok (as grok.php.net?). it'd be worth a shot, I think. Though could we get the OS on there upgraded to something a little newer? I'm not sure if Java 1.6 will run on that version of FreeBSD? Michael -- 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 (106 total -- which includes 46 feature requests) ===[*General Issues]== 50189 Open [PATCH] - unicode byte order difference between SPARC and x86 ===[Apache related]=== 47061 Open User not logged under Apache ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = 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 48478 Open Super-globals cannot be accessed with literal keys ===[COM related]== 45836 Open cannot use com ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 49421 Open Make failure with MySQL 6 and PHP 6.0-dev 50101 Open [PATCH] - Avoid name clash between global and local variable 50237 Open [PATCH] - Enable correct behaviour when building PHP6 with Sun's compilers ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[DOM XML related]== 49463 Open setAttributeNS(http://www.w3.org/2000/xmlns/,xmlns,blah;) produces error ===[Filesystem function related]== 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 46688 Open Return values differ from 5.3 and are also inconsistent 46689 Open Downcoded notices suggest unfinished code in file system? 46990 Assigned Passing UTF8 strings to filesystem functions produce wrong filenames 49479 Open move_uploaded_file is dead ===[GD related]=== 34992 Assigned imageconvolution does not respect alpha 43899 Assigned Problem in displaying right to left connected languages (like persian, arabic) ===[HTTP related]= 49273 Open setcookie() segfaults the php process when adding a positive expires value ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[ICONV related] 48538 Open iconv_strlen() does not reject invalid charset on PHP6 ===[mcrypt related]=== 46834 Assigned Range of mcrypt functions fail on PHP 6.0 ===[MySQL related] 44076 Assigned mysql_result returns nothing with blob ===[ODBC related]= 39756 Open [PATCH] Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Assigned openssl_pkey_get_public() fails when given a private key ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 49270 Open configure fails if PHP source folder path contains spaces 50420 Open pdo_sqlite.so: undefined symbol: sqlite3_libversion ===[Performance problem]== 50157 Open [patch] Replace !strlen(...) with !*... 50238 Analyzed [PATCH] - Using #defines to improve the performance of the TSRMG macro 50436 Open [PATCH] - Improving multi-threaded performance by propagating TSRMLS_C ===[PostgreSQL related]=== 48265 Open Source and result of database have different encodings. ===[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]= 47154 Open Object properties unset after setting. 49945 Open Array in multipart/form-data ===[Session related]== 44860 Open
[PHP-DEV] Bug #48843
Hello, sorry, but i can not leave comments to Bugs with status Bogus: http://bugs.php.net/bug.php?id=48843 Is this Bug really fixed/complete discovered ? In 5.3.1 my logfile is still flooded with deprecated Messages. PHP-Settings are log_errors = OFF error_reporting = E_ALL ~E_NOTICE ~E_DEPRECATED timezone is also set which was in relation to duplicate reports: date.timezone = Europe/Berlin how to solve this if it is really not a bug? Thanks, Andre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #48843
Hi Andre, I'm not 100% sure, but I believe this is related: http://bugs.php.net/bug.php?id=50251 May the source be with you, Best regards, Jess Portnoy Andre Hübner wrote: Hello, sorry, but i can not leave comments to Bugs with status Bogus: http://bugs.php.net/bug.php?id=48843 Is this Bug really fixed/complete discovered ? In 5.3.1 my logfile is still flooded with deprecated Messages. PHP-Settings are log_errors = OFF error_reporting = E_ALL ~E_NOTICE ~E_DEPRECATED timezone is also set which was in relation to duplicate reports: date.timezone = Europe/Berlin how to solve this if it is really not a bug? Thanks, Andre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
jvlad wrote:
$a = array(1);
$b = 0;
$c = $b;
foreach($a as $c);
Now you are arguing that $b should not be 1?
The two pieces of code are identical
It's just a nightmare example. I wonder have you ever see anything like
this
in real life?
Could you please let me see it too, for example in code.google.com?
If you cann't, what are you fighting for?
Interestingly, how many people will consider the code sample you
demonstrated ugly...
How many sporadic problems were already created and will be created just
beacause
of this unclear behavior of foreach?
It isn't unclear. It is perfectly consistent. Whether it is ugly or
not is irrelevant.
Even though you can kill somebody using hammer, does it mean that it _is_
the feature to
be preserved in all future versions of the hammer?
Also, you didn't answer why another function that is WIDELY used, is going
to hell.
Why don't you defend its features which go to hell with this function? Why
don't you
defent the language BC in this case? What does make your position so
selective?
Why a useless and harmful (yes it's harmful according to so many posts)
feature is preserved
while uselfull and needed function is going away?
And I don't see how your prev/next stuff has anything to do with this.
Ok. What my stuff has to do with this is there:
If prev/next were consistent with foreach, they would return first/last
element of the
array respectively as soon as they reached the boundary. But no! They
return
FALSE.
Which has nothing to do with the question at hand here. We are talking
about breaking any reference in the variables used in the loop
construct. We are not talking about any other behaviour here.
Please have a look at this page
http://www.php.net/manual/en/control-structures.foreach.php
It's where you can find the following:
--
You may have noticed that the following are functionally identical:
?php
$arr = array(one, two, three);
reset($arr);
while (list(, $value) = each($arr)) {
echo Value: $valuebr /\n;
}
foreach ($arr as $value) {
echo Value: $valuebr /\n;
}
?
--
I checked and it appears that they are not identical, quite the opposite,
they expose the
difference I mentioned before.
Each() assigns NULL to the value after the array pointer reached end.
ForEach() stays with last element in this case:
compare the output:
?php
$arr = array(one, two, three);
reset($arr);
while (list(, $value) = each($arr)) {
echo Value: $valuebr /\n;
}
var_dump($value);
?
?php
$arr = array(one, two, three);
foreach ($arr as $value) {
echo Value: $valuebr /\n;
}
var_dump($value);
?
-jv
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
Do you think we are deprecating split() just for fun? Yes, exactly. It's just made for _fun_ by core developers and brought headache to people developing in php. We are letting you know that you need to start thinking about migrating your code away from non-Unicode aware functions like ereg() and split(). Well, this filled up my php logs with some million records telling me this! Do you think it's safer to keep thinking and have an opportunity to miss anything dangerous in the logs just becase they are flooded. The Web is going entirely Unicode as is PHP 6 and these functions simply do not support Unicode strings. preg_split() is a decent substitute and you should be able to convert to it with only minor changes in your regex. If these changes are minor, why don't you provide a version of split for php6 that will make them on the fly? Why don't you consider the other scenarios that would maintain the language BC? And this has nothing to do with this thread. Please keep your rants at least somewhat on topic. It has direct relation to this thread because it's all about the policy of the changes in the language. Some pain changes are already done, some painless are not allowed. Whould you please make your position more public and clearer? -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #48843
Hello, I'm not 100% sure, but I believe this is related: http://bugs.php.net/bug.php?id=50251 ohh yes, did not found this report by previously searches :/ Thanks, could use this patch... Andre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)
hi, On Mon, Dec 28, 2009 at 10:59 AM, Michael Maclean mich...@no-surprises.co.uk wrote: Philip Olson wrote: Looks great, and much nicer. If you feel pb11[1] could handle it, then we could dedicate this box to OpenGrok (as grok.php.net?). it'd be worth a shot, I think. Though could we get the OS on there upgraded to something a little newer? I'm not sure if Java 1.6 will run on that version of FreeBSD? You can re image it (drop a mail to pair). 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] Unsetting loop variables at the end of the loop
On Mon, Dec 28, 2009 at 11:58 AM, jvlad d...@yandex.ru wrote: Do you think we are deprecating split() just for fun? Yes, exactly. It's just made for _fun_ by core developers and brought headache to people developing in php. We are letting you know that you need to start thinking about migrating your code away from non-Unicode aware functions like ereg() and split(). Well, this filled up my php logs with some million records telling me this! Do you think it's safer to keep thinking and have an opportunity to miss anything dangerous in the logs just becase they are flooded. The Web is going entirely Unicode as is PHP 6 and these functions simply do not support Unicode strings. preg_split() is a decent substitute and you should be able to convert to it with only minor changes in your regex. If these changes are minor, why don't you provide a version of split for php6 that will make them on the fly? Why don't you consider the other scenarios that would maintain the language BC? And this has nothing to do with this thread. Please keep your rants at least somewhat on topic. It has direct relation to this thread because it's all about the policy of the changes in the language. Some pain changes are already done, some painless are not allowed. Whould you please make your position more public and clearer? as far as I see, the changes depends on how many work has to be done, to preserve something. posix functions like split, and so could have been modified to work with the unicode strings, but nobody cared enough. now this request is easier to leave this way, because this scenario needs zero work against the proposed solutions. but hey: patches are welcome! :/ Tyrael -jv -- 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] Bug #48843
Sure, NP. Happy patching. May the source be with you, Best regards, Jess Portnoy Andre Hübner wrote: Hello, I'm not 100% sure, but I believe this is related: http://bugs.php.net/bug.php?id=50251 ohh yes, did not found this report by previously searches :/ Thanks, could use this patch... Andre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
On Mon, 28 Dec 2009, jvlad wrote: We are letting you know that you need to start thinking about migrating your code away from non-Unicode aware functions like ereg() and split(). Well, this filled up my php logs with some million records telling me this! Do you think it's safer to keep thinking and have an opportunity to miss anything dangerous in the logs just becase they are flooded. Bitching about upgrading and things not working is not going to get you any karma. We release release-candidates for a reason, and blindly upgrading is unprofessional. Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
We are letting you know that you need to start thinking about migrating your code away from non-Unicode aware functions like ereg() and split(). Well, this filled up my php logs with some million records telling me this! Do you think it's safer to keep thinking and have an opportunity to miss anything dangerous in the logs just becase they are flooded. Bitching about upgrading and things not working is not going to get you any karma. We release release-candidates for a reason, and blindly upgrading is unprofessional. Derick, No need to upgrade. If you write any line in php that other people are interested to run, you'll see it soon, that different people use different versions of php. If your code relies on split(), you'll get very good feedback from some of them. FYI: I didn't say anything like what you answered to. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
as far as I see, the changes depends on how many work has to be done, to preserve something. I see the same. posix functions like split, and so could have been modified to work with the unicode strings, but nobody cared enough. Because this work is not in the TODO (milestones). -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: allow for includes in php.ini
On 28-Dec-2009, at 17:43, Richard Quadling rquadl...@googlemail.com wrote: 2009/12/23 Tjerk Meesters tjerk.meest...@gmail.com: On 24-Dec-2009, at 2:47, Pierre Joye pierre@gmail.com wrote: On Wed, Dec 23, 2009 at 7:20 PM, Michael Shadle mike...@gmail.com wrote: On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen mkoppa...@php.net wrote: Hello, I think you can use PHP_INI_SCAN_DIR environment variable which should work runtime as well. still seems a bit archaic. i don''t see any reason why include support can't be added in php.ini. it will probably wind up becoming more popular and widely used than the configure option too, or the environment option... Please tell me one benefit except we support include? I don't see any. The extra files are still there, they will be loaded too, etc. The most tempting reason for me would be to have easier control of what gets loaded between SAPI's, eg load this ini for cli but not for cgi, etc. Right now this is only possible by compiling each Sapi with its own search path, which is more cumbersome. 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 For different SAPIs ... php-cli.ini, php-isapi.ini, php-cgi-fcgi.ini, etc. is what I use on Windows. Combined with registry settings for PHP (Prior to PHP5), PHP5 and PHP6, I can very easily dictate which INI file will be loaded for which version of PHP and for which SAPI. Beyond that, I can use [HOST=] for some host specific settings. All of this is with the standard windows pre-compiled binaries. I'm not sure what registry settings do, haven't seen that in Linux yet. The additional use case would be to have all common configuration settings into one ini file that would get included by the different SAPI ini files. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unsetting loop variables at the end of the loop
On 28-Dec-2009, at 20:39, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Dec 28, 2009 at 11:58 AM, jvlad d...@yandex.ru wrote: Do you think we are deprecating split() just for fun? Yes, exactly. It's just made for _fun_ by core developers and brought headache to people developing in php. We are letting you know that you need to start thinking about migrating your code away from non-Unicode aware functions like ereg() and split(). Well, this filled up my php logs with some million records telling me this! Do you think it's safer to keep thinking and have an opportunity to miss anything dangerous in the logs just becase they are flooded. The Web is going entirely Unicode as is PHP 6 and these functions simply do not support Unicode strings. preg_split() is a decent substitute and you should be able to convert to it with only minor changes in your regex. If these changes are minor, why don't you provide a version of split for php6 that will make them on the fly? Why don't you consider the other scenarios that would maintain the language BC? And this has nothing to do with this thread. Please keep your rants at least somewhat on topic. It has direct relation to this thread because it's all about the policy of the changes in the language. Some pain changes are already done, some painless are not allowed. Whould you please make your position more public and clearer? as far as I see, the changes depends on how many work has to be done, to preserve something. posix functions like split, and so could have been modified to work with the unicode strings, but nobody cared enough. Besides, nobody's forcing you to upgrade to php6. Pragmatism applied I would just retrofit split() to preg_split() in userland whenever not defined, since by right pcre cannot be disabled ;-) now this request is easier to leave this way, because this scenario needs zero work against the proposed solutions. but hey: patches are welcome! :/ Tyrael -jv -- 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] Unsetting loop variables at the end of the loop
On Mon, Dec 28, 2009 at 4:07 PM, jvlad d...@yandex.ru wrote: as far as I see, the changes depends on how many work has to be done, to preserve something. I see the same. posix functions like split, and so could have been modified to work with the unicode strings, but nobody cared enough. Because this work is not in the TODO (milestones). yeah, not anymore, but there was a thread about this on the internals that (A. make the posix unicode-ready, B, use the preg extension for the ereg functions transparently), but nobody cared enough. The whole release of the 5.3 was a little bit mess. There was a lot of feature, some of them wasn't ready for release, but it was too much finished stuff to let this slide, and we are much further from PHP6 than 5 years ago... So its kinda funny, that some stuff had to die, because some stuff, that wasnt even finished would be incompatible with. Sorry for my english. Tyrael -jv -- 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] Unsetting loop variables at the end of the loop
On Mon, Dec 28, 2009 at 4:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On 28-Dec-2009, at 20:39, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Dec 28, 2009 at 11:58 AM, jvlad d...@yandex.ru wrote: Do you think we are deprecating split() just for fun? Yes, exactly. It's just made for _fun_ by core developers and brought headache to people developing in php. We are letting you know that you need to start thinking about migrating your code away from non-Unicode aware functions like ereg() and split(). Well, this filled up my php logs with some million records telling me this! Do you think it's safer to keep thinking and have an opportunity to miss anything dangerous in the logs just becase they are flooded. The Web is going entirely Unicode as is PHP 6 and these functions simply do not support Unicode strings. preg_split() is a decent substitute and you should be able to convert to it with only minor changes in your regex. If these changes are minor, why don't you provide a version of split for php6 that will make them on the fly? Why don't you consider the other scenarios that would maintain the language BC? And this has nothing to do with this thread. Please keep your rants at least somewhat on topic. It has direct relation to this thread because it's all about the policy of the changes in the language. Some pain changes are already done, some painless are not allowed. Whould you please make your position more public and clearer? as far as I see, the changes depends on how many work has to be done, to preserve something. posix functions like split, and so could have been modified to work with the unicode strings, but nobody cared enough. Besides, nobody's forcing you to upgrade to php6. Pragmatism applied I would just retrofit split() to preg_split() in userland whenever not defined, since by right pcre cannot be disabled ;-) we are talking about php5.3. It got deprecated in that version, and there were emails on the list about discontinuing the 5.2 branch as soon as the 5.3 is ~stable. Tyrael now this request is easier to leave this way, because this scenario needs zero work against the proposed solutions. but hey: patches are welcome! :/ Tyrael -jv -- 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-DEV] is_array on objects with ArrayAccess or Iterator implementations
Has there been any discussion or decision about whether is_array() should return true for objects which implement ArrayAccess or is there another function already available which checks for either being the case? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
Op 28-12-2009 17:30, Clint Priest schreef: Has there been any discussion or decision about whether is_array() should return true for objects which implement ArrayAccess or is there another function already available which checks for either being the case? How about $x instanceOf ArrayAccess ? -- Jille -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
Unfortunately $x instanceOf ArrayAccess doesn't return true when $x is indeed an array. Jille Timmermans wrote: Op 28-12-2009 17:30, Clint Priest schreef: Has there been any discussion or decision about whether is_array() should return true for objects which implement ArrayAccess or is there another function already available which checks for either being the case? How about $x instanceOf ArrayAccess ? -- Jille -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
Hello, On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest cpri...@warpmail.net wrote: Unfortunately $x instanceOf ArrayAccess doesn't return true when $x is indeed an array. Making is_array return true for objects implementing ArrayAccess is a bad idea, for two main reasons: 1) is_array is a type check, and we should still be able to distinguish real arrays from objects 2) ArrayAccess does not guarantee that an object will behave like an array, (e.g. you won't be able to use sort() on an object implementing ArrayAccess. If, in your case, you want to accept both arrays and ArrayAccess objects, I guess if (is_array($v) || $v instanceof ArrayAccess) is a sufficiently good way to check. Best, Jille Timmermans wrote: Op 28-12-2009 17:30, Clint Priest schreef: Has there been any discussion or decision about whether is_array() should return true for objects which implement ArrayAccess or is there another function already available which checks for either being the case? How about $x instanceOf ArrayAccess ? -- Jille -- 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] Re: alternative to the fopen() hack in autoloaders
Bump.
I really think we need to think about this problem that Lukas has
brought up.
Now that the magic words have come up ('counting stat calls'), can we
get someone to weight in on the possibility of both having some kind of
include_path resolver in the 5.3 branch, and it's impact of stat calls
in PHP both without an optimizer and with an optimizer?
It seems like enough interest is here, as well as code, and those
willing to contribute the functionality.. What about on the policy front?
As you can tell, I am itching to see where this goes ;)
-ralph
Mikko Koppanen wrote:
On Wed, Dec 9, 2009 at 2:04 AM, Stanislav Malyshev s...@zend.com wrote:
Hi!
I think stream_resolve_include_path() should be changed to work through
zend_resolve_path, in any case. Also, what is the reason it can't be in 5.3
too?
I'd like to both fix stream_resolve_include_path() and get it into 5.3, any
objections to that?
Hi,
this might work against PHP_5_3 and trunk:
http://valokuva.org/patches/php/new/stream_resolve_include_path.txt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
Etienne Kneuss wrote:
On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest cpri...@warpmail.net wrote:
Unfortunately $x instanceOf ArrayAccess doesn't return true when $x is
indeed an array.
Making is_array return true for objects implementing ArrayAccess is a
bad idea, for two main reasons:
1) is_array is a type check, and we should still be able to
distinguish real arrays from objects
That's true of course, definitely would need to be able to distinguish.
2) ArrayAccess does not guarantee that an object will behave like an
array, (e.g. you won't be able to use sort() on an object implementing
ArrayAccess.
I wonder if this is something that users would be expecting, that any
function which took an array would also take an object that implements
certain interfaces (such as ArrayAccess and perhaps Countable).
If, in your case, you want to accept both arrays and ArrayAccess
objects, I guess if (is_array($v) || $v instanceof ArrayAccess) is a
sufficiently good way to check.
I'm finding myself implementing ArrayAccess more and more often because
its so transparent to the consumer. The reason this came up is because
I was considering returning all arrays from a certain section of my
shared code library always be an array object so that things like
$tblArray-pluck('Value') could be done, rather than array_pluck() type
functionality.
That got me to thinking about all of the is_array() calls I would need
to replace throughout the codebase.
Would it be terribly difficult to make objects with ArrayAccess
completely interchangable anywhere an array element would be required by
a function?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
Hi,
On Tue, Dec 29, 2009 at 1:27 AM, Clint Priest cpri...@warpmail.net wrote:
Etienne Kneuss wrote:
On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest cpri...@warpmail.net
wrote:
Unfortunately $x instanceOf ArrayAccess doesn't return true when $x is
indeed an array.
Making is_array return true for objects implementing ArrayAccess is a
bad idea, for two main reasons:
1) is_array is a type check, and we should still be able to
distinguish real arrays from objects
That's true of course, definitely would need to be able to distinguish.
2) ArrayAccess does not guarantee that an object will behave like an
array, (e.g. you won't be able to use sort() on an object implementing
ArrayAccess.
I wonder if this is something that users would be expecting, that any
function which took an array would also take an object that implements
certain interfaces (such as ArrayAccess and perhaps Countable).
If, in your case, you want to accept both arrays and ArrayAccess
objects, I guess if (is_array($v) || $v instanceof ArrayAccess) is a
sufficiently good way to check.
I'm finding myself implementing ArrayAccess more and more often because its
so transparent to the consumer. The reason this came up is because I was
considering returning all arrays from a certain section of my shared code
library always be an array object so that things like
$tblArray-pluck('Value') could be done, rather than array_pluck() type
functionality.
That got me to thinking about all of the is_array() calls I would need to
replace throughout the codebase.
Would it be terribly difficult to make objects with ArrayAccess completely
interchangable anywhere an array element would be required by a function?
Yes, definitely, it would be a quite big amount of work (basically
rewriting every functions dealing with arrays), and the interface that
ArrayAccess proposes isn't enough for most array tasks.
--
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] is_array on objects with ArrayAccess or Iterator implementations
On Mon, December 28, 2009 10:30 am, Clint Priest wrote: Has there been any discussion or decision about whether is_array() should return true for objects which implement ArrayAccess or is there another function already available which checks for either being the case? I really would prefer that is_array *not* return true unless something really is a PHP array datatype. I've had too much grief with psuedo-arrays from SimpleXML and/or SPL or whatever it is that didn't quite implement *everything* an array does, or didn't quite behave the way I expected with regards to various functions. Surely there can be some kind of is_a or instanceof or other operator that would be more appropriate than overloading the built-in is_array function. -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
On Mon, December 28, 2009 6:27 pm, Clint Priest wrote:
Etienne Kneuss wrote:
On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest
cpri...@warpmail.net wrote:
Unfortunately $x instanceOf ArrayAccess doesn't return true when $x
is
indeed an array.
Making is_array return true for objects implementing ArrayAccess is
a
bad idea, for two main reasons:
1) is_array is a type check, and we should still be able to
distinguish real arrays from objects
That's true of course, definitely would need to be able to
distinguish.
is_array is precisely what we expect to be able to use to distinguish.
2) ArrayAccess does not guarantee that an object will behave like an
array, (e.g. you won't be able to use sort() on an object
implementing
ArrayAccess.
I wonder if this is something that users would be expecting, that any
function which took an array would also take an object that implements
certain interfaces (such as ArrayAccess and perhaps Countable).
Certainly if is_array returns TRUE, I would expect it to *be* an
array, and do what a PHP array is supposed to do. :-)
If, in your case, you want to accept both arrays and ArrayAccess
objects, I guess if (is_array($v) || $v instanceof ArrayAccess) is
a
sufficiently good way to check.
A simple one-liner:
function is_arrayaccess ($object){
return (is_array($object) || $object instanceof ArrayAccess);
}
and a global search and replace for is_array should not tax your
resources.
Another option is to have a class that implements ArrayAccess in the
simplest easiest way, by having a private property which is a true
is_array() built-in, and all the methods just work on that private
property.
You can pass that out from your library, and internally it can use the
array itself. You may even find a combination of private/protected
that lets you expose the internal array when it is desirable to access
it directly.
Would it be terribly difficult to make objects with ArrayAccess
completely interchangable anywhere an array element would be required
by
a function?
Even if you could guarantee that every function would work it's
still a Bad Idea.
What are you going to do about var_dump and print_r?
Are they going to lie to me and tell me it's an array and print it out
exactly like an array?
Or is it going to distinguish, as it should?
No matter how much you love ArrayAccess, it's not an array. It's a
class that implements specific array-like feature set.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
