Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, 12 Oct 2009, jval...@eoni.com wrote: Mark Krenz wrote: 7. PHP Cookbook from 2006 Has mixed examples, some using ereg and some using preg_match In PHP Cookbook, the only use of ereg I found was in the section where the books was explaining how to convert from ereg to preg_match. Or an occasional mention that said you could do it with ereg but preg_match was better. But, I might have missed something. No. You are correct. We switched over all the examples to preg when we revised the book for the second edition. As we said in the introduction to our Regular Expressions chapter: "In general, there's no longer any reason to use the ereg functions." We also included a Recipe for converting from ereg to preg, including how to use addcslashes() to escape your delimiter, and dechex() when you're using an integer instead of a string as an input value for a pattern or replacement (a valid, and highly useful case in some instances, but very esoteric for most programs). So, yes, there is some work that needs to be done to upgrade scripts, and, yes, there are some dank corner cases, but they are relatively straight forward to go after, shed light on, and clean up. As someone who had to convert legacy code from PHP/FI to PHP 3, when PHP changed its string contactenation operator, of all things, I can say that subbing ereg() for preg() is an easier transition, especially when it has the value of letting PHP 6 seamlessly support Unicode. -adam -- a...@trachtenberg.com | http://www.trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
On 13.10.2009, at 17:26, Ulf Wendel wrote: Alexey Zakhlestin schrieb: On 13.10.2009, at 16:10, Jille Timmermans wrote: Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. Definitely +1 from me. As long as ext/mysql is bundled with php (which means "officially supported") I see no reason to reject simple patches Definetly -1 from my side: what maked warning count different from prepared statements? lack of patch If ext/mysql would not have such a tremendous user base, I would even suggest to disable it by default. there was a chance to mark it "deprecated" in 5.3 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Alexey Zakhlestin schrieb: On 13.10.2009, at 16:10, Jille Timmermans wrote: Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. Definitely +1 from me. As long as ext/mysql is bundled with php (which means "officially supported") I see no reason to reject simple patches Definetly -1 from my side: what maked warning count different from prepared statements? If ext/mysql would not have such a tremendous user base, I would even suggest to disable it by default. Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
On 13.10.2009, at 16:10, Jille Timmermans wrote: Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. Definitely +1 from me. As long as ext/mysql is bundled with php (which means "officially supported") I see no reason to reject simple patches -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Jille Timmermans schrieb: Only ext/mysqli gives you access to all functionality of MySQL 4.1 and above, e.g. charset and prepared statements. Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. ext/mysql already "hides" functionality, for example, prepared statements. If you add all the missing pieces to ext/mysql you get ext/mysqli... Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Ulf Wendel schreef: Jille Timmermans schrieb: I have 'implemented' MySQL's mysql_warning_count() function. ( http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html ) mysql_warning_count() is available in MySQL's C-api in >3.23, >4.1 and >5 I am not a big fan of adding anything to ext/mysql that is not security relevant or mission critical. mysql_warning_count() is a convenience function. It is performance 'critical': Without this function I will have to query 'SHOW WARNINGS' after every query, which won't be good for the performance. Let ext/mysql run out and use ext/mysqli instead. ext/mysqli is around since PHP 5.0 = 2004 = 5 years. It can be considered as faily stable. It is as easy to use as ext/mysql. Performance is virtually identical. ext/mysqli didn't have persistent connections till 5.3; this made it impossible for me to switch to it at the time we had to decide. Only ext/mysqli gives you access to all functionality of MySQL 4.1 and above, e.g. charset and prepared statements. Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. I see no reasons for updating ext/mysql when there is a successor (for so long). It should have been included a long time ago, IMHO. -- Jille Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
http://wiki.php.net/rfc/pdonotices Samuel. 2009/10/12 Samuel ROZE : > Here is what I expect for the notices fetching in PDO: > http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdf > > Samuel. > > Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit : > [...] >> >> well .. what Pierre (and me supporting him) was asking for is to >> create an RFC page that details the actual sticking points with this >> feature so that they can then discuss the above points more if need >> be .. or we can take a vote on how to proceed. You are asking the >> general community to vote on something where there is no clear >> document describing the state of the discussion. Remember not >> everybody reads all messages and even I am likely to have forgotten a >> point raised in this thread by now .. and I have payed attention to >> this thread from the very beginning. Writing an RFC is not about >> making your life miserable .. and its not about stalling your request >> either. >> >> regards, >> Lukas Kahwe Smith >> m...@pooteeweet.org >> >> >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
