[PHP-DEV] PHP 5 Bug Summary Report
PHP 5 Bug Database summary - http://bugs.php.net/ Num Status Summary (1513 total -- which includes 967 feature requests) ===[*Compression related]= 49831 Open zlib.output_compression ===[*Directory/Filesystem functions] 49620 Assigned is_writeable does not work using netshare and normal user rights ===[*General Issues]== 48597 Open Unclosed array keys break space escaping in $_GET/POST/REQUEST 49774 Feedback defined delivers wrong value ===[*Network Functions]=== 48167 To be documented undefined function checkdnsrr() ===[*Programming Data Structures]= 49821 Open unserialize of references ===[*Unicode Issues]== 49687 Open 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 49224 Assigned Segmentation fault 49677 Open ini parser crashes with zend_extension = ${extension_dir}"/foo.so" 49793 Feedback Max open files limit hit when specifying error_reporting in vhost config ===[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]== 45217 Open crash if -z and -m are used together 47412 Open 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 49472 Verified Constants defined in Interfaces can be overridden 49828 Open class-constant can't be set to negative infinity ===[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
Re: [PHP-DEV] Re: Patch: Use notices in PDO
Hi, >> hmm why do you think that PDO would need to take special care about >> this? seems like this is the job of the PDO using code .. > > Depending on how PDO's code is written, it could inadvertently blow away > metadata without a user knowing it. > >> but it does raise one concern that i did not think about before: one >> potential issue is that with unbuffered queries (which are on by >> default) in MySQL you can only have one open result set at a time > > A good example. > >> then again notices are usually only for insert/delete/update .. > > I was thinking the same thing. Even data manipulation queries can run > into issues. If the code is written poorly, it could clobber things like > affected row counts, etc. Given the recent posts, I'd vote to only add whatever is needed for the drivers to access the extra data. That means to only add the specific pgsql code to gather notices as the mysql and oracle drivers are already capable of fetching warnings/dbms_output. To me, this would be much clearer: a common interface to access different kind of data would definitely not be a step forward in terms of abstraction. Cheers -- Matteo Beccati -- 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 (101 total -- which includes 44 feature requests) ===[*Compile Issues]== 49270 Open configure fails if PHP source folder path contains spaces ===[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 49301 Open HAVE_GLOB is not detected correctly 49421 Open Make failure with MySQL 6 and PHP 6.0-dev ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[Documentation problem] 49126 Open unicode_set_error_handler undocumented ===[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 ===[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 ===[Reflection related]=== 49734 Open toString must return string value ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to "./" (and other ini settings) causes apache crash 47756 Open Segfault on HTML Purifier test suite ===[Scripting Engine problem]= 47154 Open Object properties unset after setting. ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[SimpleXML related]
Re: [PHP-DEV] Re: Patch: Use notices in PDO
hi, On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati wrote: > Given the recent posts, I'd vote to only add whatever is needed for the > drivers to access the extra data. That means to only add the specific > pgsql code to gather notices as the mysql and oracle drivers are already > capable of fetching warnings/dbms_output. To me, this would be much > clearer: a common interface to access different kind of data would > definitely not be a step forward in terms of abstraction. I'd to vote for nothing right now as I can't vote while shooting in the dark :) In other words I do think that this addition is a right step in terms of abstraction (and is mostly a debugging feature too). However as it has been said during this discussion we have to be careful. The only to be sure about the right way to do it is to have an implementation for each driver and valid it. A little RFC can help to keep tracks of everything. I like to go ahead with the implementation and then see if it is a good thing or not, or if it is possible at all for all drivers. 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] Configuration in the php.ini file
Hi, On Fri, 2009-10-09 at 15:21 +0200, Samuel ROZE wrote: > I wanted to change a parameter in my PDO class, with the fourth > PDO::_construct arg. But, I've many projects, which uses PDO, with one > "new PDO" per project. The problem is that I have to change the source > of every projects... > > Why isn't there an PDO section in the php.ini file ? For instance: > > pdo.is_persistent = 1 > pdo.fetch_notices = 1 Using these means two places have to be changed and monitored - the application-specify configuration holding DSN, username and password and the php.ini additionally. Some applications might have trouble if there expectations about the environment isn't correct. The more ini settings you have the more trouble ... these won'T be as troublesome as magic_quotes but could still lead to unexpected behavior if the developer doesn't expect them in some cases. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Hi, On Wed, 2009-10-07 at 15:55 +0200, Lukas Kahwe Smith wrote: > yeah .. its certainly a valid question. > we have stuff like lastInsertId(), which depending on the driver > either gets the current value of a sequence or the last id generated > for the connection. > so going by that example unifying things under a common API makes > sense if that means that it makes writing portable code easier. For that we shouldn't do just random small changes but take a look at the whole picture (PDO2?) Most of the things need new hooks or change PDO APIs in a breaking way so they can't be done in 5.3, so maybe the time till 6.0 can be used to really identify and collect the issues and then either refactor or recreate it depending on the results. There was a group once working on these things which ended in political/legal/... discussions maybe the effort can be revived now, two years later. What I see is that many people would like having a proper abstraction layer (what ever is to be abstracted) and PDO has too many rough edges. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Use notices in PDO
Hi, On Thu, 2009-10-08 at 23:51 +0200, Samuel ROZE wrote: > There is a patch to implements this function into PDO: > http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patch Just a quick note: This changes the ABI so it can't be done in 5.3. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Creating an experimental syntax
Dear Internals Ok... So i figured out that the way to make a scala style multi line function declaration was simply to do this: ### zend_language_parser.y ### unticked_function_declaration_statement: function is_reference T_STRING { zend_do_begin_function_declaration(&$1, &$3, 0, $2.op_type, NULL TSRMLS_CC); } '(' parameter_list ')' '=' '{' inner_statement_list '}' { zend_do_end_function_declaration(&$1 TSRMLS_CC); } ; ### PHP ### def new_function() = { echo "It works!\n"; } But I have been stuck the last couple of hours trying to make support for a one line function declaration without the '{}'. Example: def double($x) = return 2 * $x; I cant seem to find out what token to use for a new line? Any thoughts? Thx a lot from confused guy Rune Kaagaard Denmark -- 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
On 12.10.2009, at 12:07, Pierre Joye wrote: hi, On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati wrote: Given the recent posts, I'd vote to only add whatever is needed for the drivers to access the extra data. That means to only add the specific pgsql code to gather notices as the mysql and oracle drivers are already capable of fetching warnings/dbms_output. To me, this would be much clearer: a common interface to access different kind of data would definitely not be a step forward in terms of abstraction. I'd to vote for nothing right now as I can't vote while shooting in the dark :) In other words I do think that this addition is a right step in terms of abstraction (and is mostly a debugging feature too). However as it has been said during this discussion we have to be careful. The only to be sure about the right way to do it is to have an implementation for each driver and valid it. A little RFC can help to keep tracks of everything. I like to go ahead with the implementation and then see if it is a good thing or not, or if it is possible at all for all drivers. yeah .. it does seem like its trickier than i originally thought. moreover having a proper RFC will help document why we decided to add this feature (or not add), which can help for future similar discussion. the aim of the RFC is therefore to document the actual feature, the potential issues and the pro's and con's about having this inside PDO core. and of course links to proposed patches. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [patch] mysql_warning_count() for ext/mysql
Hello all, Not sure whether this is the right place to post; but it seemed a little bit better than php...@. 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 This function returns the number of warnings from the previous query. In some queries (INSERT INTO .. VALUES (..), (..); INSERT INTO .. SELECT; etc) mysql_info() was usable to return the number of warnings; but for single-row inserts mysql_info() returns false. The function is very straightforward, almost the same as mysql_thread_id(). The patch is available at http://jille.hexon.cx/mysql-warning-count.diff It is based on PHP 5.3.0 and at least works for me. -- Jille -- 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: 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. 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. Only ext/mysqli gives you access to all functionality of MySQL 4.1 and above, e.g. charset and prepared statements. I see no reasons for updating ext/mysql when there is a successor (for so long). 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
[PHP-DEV] Why is ereg being deprecated?
I just found this out a couple days ago when I checked the ereg manual page for something and was shocked. I searched around a bit but couldn't find a straight answer on why this function is being removed? Did the deprecation notice just get made in 5.3 or has it been there longer than that? Thanks, Mark -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
It was fat, slow and everything that you can do with POSIX regex you can easily do with PCRE regex, which is faster. It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6. Cheers, On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote: > > I just found this out a couple days ago when I checked the ereg manual > page for something and was shocked. I searched around a bit but > couldn't find a straight answer on why this function is being removed? > Did the deprecation notice just get made in 5.3 or has it been there > longer than that? > > Thanks, > Mark > > -- > Mark S. Krenz > IT Director > Suso Technology Services, Inc. > http://suso.org/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
The real answer is that there is no Unicode support in the ereg functions, and like it or not, the world is going Unicode. -Rasmus Guilherme Blanco wrote: > It was fat, slow and everything that you can do with POSIX regex you > can easily do with PCRE regex, which is faster. > > It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6. > > Cheers, > > On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote: >> I just found this out a couple days ago when I checked the ereg manual >> page for something and was shocked. I searched around a bit but >> couldn't find a straight answer on why this function is being removed? >> Did the deprecation notice just get made in 5.3 or has it been there >> longer than that? >> >> Thanks, >> Mark >> >> -- >> Mark S. Krenz >> IT Director >> Suso Technology Services, Inc. >> http://suso.org/ >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Guilherme Blanco wrote: It was fat, slow and everything that you can do with POSIX regex you can easily do with PCRE regex, which is faster. It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6. Cheers, On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote: I just found this out a couple days ago when I checked the ereg manual page for something and was shocked. I searched around a bit but couldn't find a straight answer on why this function is being removed? Did the deprecation notice just get made in 5.3 or has it been there longer than that? Just to add... I've found many regular expressions to evaluate an order of magnitude faster via preg than via ereg. The speed difference is well worth your time switching to preg. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Ok, let me first say that I have no problem with deprecating it in favor of PCRE. Being a heavy Perl developer too, I'm more used to PCRE syntax anyways so it will be easier to only remember one syntax between languages. Secondly, I've been using PHP since version 2 and as far as I can remember ereg and the POSIX regex syntax has been in PHP for that long if not as long as PHP has existed. Deprecating functionality in software is tricky enough when its a minor function, but when its a major function in a major programming language it is something entirely different. Removing a function because its fat, slow and doesn't have unicode support isn't enough of a justification for removing a major function like ereg that is used in probably 90% of all PHP applications. If there was some kind of security issue that couldn't be fixed without removing it then that would be different, but from what you said I don't think there is. PHP 6 already has some major changes to it that will affect many people and slow its adoption. Removing ereg might kill adoption of it altogether or run the risk of PHP being forked. My suggestion is that you delay removal of the function until PHP 7 or even 8. This will give people a lot more time to learn about change and most major app developers will find out about it and make the change. Also, distributions that package PHP will have at least a couple minor versions released prior to it being removed, which I think is VERY important. Please, let's discuss this. Mark On Mon, Oct 12, 2009 at 03:51:48PM GMT, Guilherme Blanco [guilhermebla...@gmail.com] said the following: > It was fat, slow and everything that you can do with POSIX regex you > can easily do with PCRE regex, which is faster. > > It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6. > > Cheers, > > On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote: > > > > I just found this out a couple days ago when I checked the ereg manual > > page for something and was shocked. I searched around a bit but > > couldn't find a straight answer on why this function is being removed? > > Did the deprecation notice just get made in 5.3 or has it been there > > longer than that? > > > > Thanks, > > Mark > > > > -- > > Mark S. Krenz > > IT Director > > Suso Technology Services, Inc. > > http://suso.org/ > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- > Guilherme Blanco - Web Developer > CBC - Certified Bindows Consultant > Cell Phone: +55 (16) 9215-8480 > MSN: guilhermebla...@hotmail.com > URL: http://blog.bisna.com > São Paulo - SP/Brazil -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Lack of Unicode support is enough of a problem in that PHP6 will be all Unicode all the time, so these functions simply won't work as they are today. It would take someone sitting down and figuring out how to emulate this stuff in a way that makes sense in a Unicode world for them to come back, and unless we get a volunteer to do that, they are gone. It is not a question of simply leaving in what we have today. It technically won't work. -Rasmus Mark Krenz wrote: > Ok, let me first say that I have no problem with deprecating it in > favor of PCRE. Being a heavy Perl developer too, I'm more used to PCRE > syntax anyways so it will be easier to only remember one syntax between > languages. > > Secondly, I've been using PHP since version 2 and as far as I can > remember ereg and the POSIX regex syntax has been in PHP for that long > if not as long as PHP has existed. > > Deprecating functionality in software is tricky enough when its a > minor function, but when its a major function in a major programming > language it is something entirely different. Removing a function > because its fat, slow and doesn't have unicode support isn't enough of a > justification for removing a major function like ereg that is used in > probably 90% of all PHP applications. If there was some kind of > security issue that couldn't be fixed without removing it then that > would be different, but from what you said I don't think there is. > > PHP 6 already has some major changes to it that will affect many > people and slow its adoption. Removing ereg might kill adoption of it > altogether or run the risk of PHP being forked. > > My suggestion is that you delay removal of the function until PHP 7 or > even 8. This will give people a lot more time to learn about change and > most major app developers will find out about it and make the change. > Also, distributions that package PHP will have at least a couple minor > versions released prior to it being removed, which I think is VERY > important. > > Please, let's discuss this. > > Mark > > On Mon, Oct 12, 2009 at 03:51:48PM GMT, Guilherme Blanco > [guilhermebla...@gmail.com] said the following: >> It was fat, slow and everything that you can do with POSIX regex you >> can easily do with PCRE regex, which is faster. >> >> It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6. >> >> Cheers, >> >> On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote: >>> I just found this out a couple days ago when I checked the ereg manual >>> page for something and was shocked. I searched around a bit but >>> couldn't find a straight answer on why this function is being removed? >>> Did the deprecation notice just get made in 5.3 or has it been there >>> longer than that? >>> >>> Thanks, >>> Mark >>> >>> -- >>> Mark S. Krenz >>> IT Director >>> Suso Technology Services, Inc. >>> http://suso.org/ >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> >> -- >> Guilherme Blanco - Web Developer >> CBC - Certified Bindows Consultant >> Cell Phone: +55 (16) 9215-8480 >> MSN: guilhermebla...@hotmail.com >> URL: http://blog.bisna.com >> São Paulo - SP/Brazil > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Just to clarify. You mean that with the changes you've made for Unicode support in PHP 6, that current POSIX based ereg expressions will not work the same? On Mon, Oct 12, 2009 at 04:18:29PM GMT, Rasmus Lerdorf [ras...@lerdorf.com] said the following: > Lack of Unicode support is enough of a problem in that PHP6 will be all > Unicode all the time, so these functions simply won't work as they are > today. It would take someone sitting down and figuring out how to > emulate this stuff in a way that makes sense in a Unicode world for them > to come back, and unless we get a volunteer to do that, they are gone. > It is not a question of simply leaving in what we have today. It > technically won't work. > > -Rasmus > > Mark Krenz wrote: > > Ok, let me first say that I have no problem with deprecating it in > > favor of PCRE. Being a heavy Perl developer too, I'm more used to PCRE > > syntax anyways so it will be easier to only remember one syntax between > > languages. > > > > Secondly, I've been using PHP since version 2 and as far as I can > > remember ereg and the POSIX regex syntax has been in PHP for that long > > if not as long as PHP has existed. > > > > Deprecating functionality in software is tricky enough when its a > > minor function, but when its a major function in a major programming > > language it is something entirely different. Removing a function > > because its fat, slow and doesn't have unicode support isn't enough of a > > justification for removing a major function like ereg that is used in > > probably 90% of all PHP applications. If there was some kind of > > security issue that couldn't be fixed without removing it then that > > would be different, but from what you said I don't think there is. > > > > PHP 6 already has some major changes to it that will affect many > > people and slow its adoption. Removing ereg might kill adoption of it > > altogether or run the risk of PHP being forked. > > > > My suggestion is that you delay removal of the function until PHP 7 or > > even 8. This will give people a lot more time to learn about change and > > most major app developers will find out about it and make the change. > > Also, distributions that package PHP will have at least a couple minor > > versions released prior to it being removed, which I think is VERY > > important. > > > > Please, let's discuss this. > > > > Mark > > > > On Mon, Oct 12, 2009 at 03:51:48PM GMT, Guilherme Blanco > > [guilhermebla...@gmail.com] said the following: > >> It was fat, slow and everything that you can do with POSIX regex you > >> can easily do with PCRE regex, which is faster. > >> > >> It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6. > >> > >> Cheers, > >> > >> On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote: > >>> I just found this out a couple days ago when I checked the ereg manual > >>> page for something and was shocked. I searched around a bit but > >>> couldn't find a straight answer on why this function is being removed? > >>> Did the deprecation notice just get made in 5.3 or has it been there > >>> longer than that? > >>> > >>> Thanks, > >>> Mark > >>> > >>> -- > >>> Mark S. Krenz > >>> IT Director > >>> Suso Technology Services, Inc. > >>> http://suso.org/ > >>> > >>> -- > >>> PHP Internals - PHP Runtime Development Mailing List > >>> To unsubscribe, visit: http://www.php.net/unsub.php > >>> > >>> > >> > >> > >> -- > >> Guilherme Blanco - Web Developer > >> CBC - Certified Bindows Consultant > >> Cell Phone: +55 (16) 9215-8480 > >> MSN: guilhermebla...@hotmail.com > >> URL: http://blog.bisna.com > >> São Paulo - SP/Brazil > > > > > -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
hi, On Mon, Oct 12, 2009 at 6:22 PM, Mark Krenz wrote: > > Just to clarify. You mean that with the changes you've made for > Unicode support in PHP 6, that current POSIX based ereg expressions will > not work the same? The ereg functions cannot work with Unicode and can't be fixed without rewriting them. Nobody likes to do it as pcre works just fine and has many active maintainers (inside and outside php). 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: Use notices in PDO
Sorry but what is ABI ? Le lundi 12 octobre 2009 à 12:50 +0200, Johannes Schlüter a écrit : > Hi, > > On Thu, 2009-10-08 at 23:51 +0200, Samuel ROZE wrote: > > There is a patch to implements this function into PDO: > > http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patch > > Just a quick note: This changes the ABI so it can't be done in 5.3. > > johannes > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Use notices in PDO
2009/10/12 Samuel ROZE : > Sorry but what is ABI ? http://en.wikipedia.org/wiki/Application_binary_interface -- 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] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com] said the following: > > The ereg functions cannot work with Unicode and can't be fixed without > rewriting them. Nobody likes to do it as pcre works just fine and has > many active maintainers (inside and outside php). > But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the only one who thought this. Again, this isn't a debate on which is better, I only want to STRONGLY stress that I think its a big mistake to remove it in 6.0. If you wanted to remove it in 6.0, you should have sent out the deprecated warning in the whole 5.0 series, not just 5.3, which most people don't even use. If nobody simply wants to do the work to make sure ereg is ready for PHP 6 and unicode support, then you are not doing your job. I hate to call it a job because I'm sure that you all enjoy doing PHP development, but there are times when you have to bite the bullet and do the hard work because its your responsibility to do so. If your only defense when the army of developers come banging at your door about why ereg doesn't work anymore is that you didn't feel like doing the work, PHP is going to lose a lot of support and you as developers will lose a lot of respect. I feel like I shouldn't even have to tell you this, you develop a programming language that is known by millions and runs web apps that are used by the whole Internet. If ereg isn't ready yet then 6.0 should be delayed until it is ready. Somehow I doubt that you'd have trouble finding volunteers to do the work if they know what was at stake. There are probably a lot of people out there perhaps even on this list that would love to show off their chops by submitting some piece of code that will get them noticed. If those of you that have responded are not willing to do the work, then open it up for review by others. Send out a call for volunteers. Maybe my inquiry will spark some interest. Imagine being able to say that you were the one that saved the ereg function. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Wow, you sure do assume a lot of things about PHP and its development community. I have never seen your name on this list before and (now I am assuming) do not know the state of development of PHP6 (as in that its more or less on halt until someone gets things going again). On 12.10.2009, at 18:57, Mark Krenz wrote: On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com ] said the following: The ereg functions cannot work with Unicode and can't be fixed without rewriting them. Nobody likes to do it as pcre works just fine and has many active maintainers (inside and outside php). But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the only one who thought this. Maybe try to substantiate that argument with a google code search or something. Personally I have seen quite the opposite, then again I have been actively encouraging people to use preg since about 5 or more years now. Again, this isn't a debate on which is better, I only want to STRONGLY stress that I think its a big mistake to remove it in 6.0. If you wanted to remove it in 6.0, you should have sent out the deprecated warning in the whole 5.0 series, not just 5.3, which most people don't even use. If nobody simply wants to do the work to make sure ereg is ready for PHP 6 and unicode support, then you are not doing your job. I hate to call it a job because I'm sure that you all enjoy doing PHP development, but there are times when you have to bite the bullet and do the hard work because its your responsibility to do so. Our job for the most of us is to convince our boss's that the time we spend on company time is a worthwhile investment. There are of course people who work on PHP for fun in their spare time .. not sure if job fits the description for stuff they want to do. Anyways, that doesnt mean that either of the two mentioned "groups" of developers isnt doing a lot of boring tedious work for PHP as it is. I feel like I shouldn't even have to tell you this, you develop a programming language that is known by millions and runs web apps that are used by the whole Internet. Well the whole internet hasnt setup a donation box to pay for developers to work on stuff like this full time. If ereg isn't ready yet then 6.0 should be delayed until it is ready. Somehow I doubt that you'd have trouble finding volunteers to do the work if they know what was at stake. There are probably a lot of people out there perhaps even on this list that would love to show off their chops by submitting some piece of code that will get them noticed. If those of you that have responded are not willing to do the work, then open it up for review by others. Send out a call for volunteers. Maybe my inquiry will spark some interest. Imagine being able to say that you were the one that saved the ereg function. Well again an assumption .. no we do not have enough developers to do all the cool things we can think up and still fix bugs, document stuff etc. Feel free to step up .. but it makes no sense to start a php.net plea for help to get something ported to PHP6, where we will have a perfectly fine alternative. regards, Lukas Kahwe Smith m...@pooteeweet.org -- 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
On 12.10.2009, at 19:00, Samuel ROZE wrote: Hi, I'm writing here to take a point about the discussion. On one side, you want to turn this functionality to a global function, like it is describe into this patch and on the other side, you said that on MySQL and Oracle we can get this notices with queries so it is not needed for them but only for PostgreSQL. Before continuing every development I want to make like a survey about what I (or we) will do. Here are my proposals: 1. Make this functionality only for PostgreSQL, with a "pgGetNotices" function. 2. Continue development for MySQL & Oracle, with the known that if notices recuperation is enabled, PDO will have to do queries. 3. Let development at this stage waiting that somebody else propose a notices patch for other Database than PostgreSQL. Note: For MySQL there'is the mysql_info function (http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html) 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
Re: [PHP-DEV] Why is ereg being deprecated?
Mark Krenz wrote: > But I'm willing to bet that the majority of people are using ereg, not > PCRE. I've known about PCRE in PHP for a while now, but I continue to > use ereg because I thought it had better support in PHP and that it was > the more "official" function. Guess I was wrong. I'm sure I'm not the I guess that's exactly the reason why it is deprecated now: To indicate that preg_* are the way to go. > Again, this isn't a debate on which is better, I only want to STRONGLY > stress that I think its a big mistake to remove it in 6.0. If you wanted As far as I understand ereg will be moved to a PECL-extension to keep it around for people who can't switch. > If ereg isn't ready yet then 6.0 should be delayed until it is ready. It probably never will be... Don't get too worked up on this because (as far as I understand the messages on internals) PHP 6 will not be a drop-in replacement for PHP 5.3 anyway. Hosters will have to configure it (like installing the PECL-extension), developers will have to adapt some code. I'm not sure if I'm right but that's how I understand the plans, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 6:57 PM, Mark Krenz wrote: > On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com] > said the following: >> >> The ereg functions cannot work with Unicode and can't be fixed without >> rewriting them. Nobody likes to do it as pcre works just fine and has >> many active maintainers (inside and outside php). >> > > But I'm willing to bet that the majority of people are using ereg, not > PCRE. I've known about PCRE in PHP for a while now, but I continue to > use ereg because I thought it had better support in PHP and that it was > the more "official" function. Guess I was wrong. I'm sure I'm not the > only one who thought this. Let me use another example to make you understand the situation. I bought a car, which is great, I can repair it myself, can drive anywhere I want, etc. 50 years later, the gaz reserve are out (bio gaz etc. as well). I can "STRONGLY stress" anyone in the world to make my car works with the new combustible, that won't help, my car simply does not work with the new combustible. I have now two choices: 1. adapt myself and walk more (or buy a new car) 2. patch my car to work with the new combustible and provide it to the cars developers so everyone else can enjoy the old cars for the next decade. Please note that I knew for years that I won't find gaz anymore at some point. Shorter version: Topics have been discussed to death, move on, nothing to see. 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] Why is ereg being deprecated?
On 12.10.2009, at 19:12, Pierre Joye wrote: Shorter version: Topics have been discussed to death, move on, nothing to see. actually in the spirit of how i documented the decision about ifsetor() [1] and the fact that contrary to "popular" opinion, the time of core devs is limited, it would be nice of someone would document the points raised by with "sides" about the deprecation of ereg in 5.3 and the removal in 6.0. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] http://pooteeweet.org/blog/1200 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
This thread inspired me to google for a POSIX to PCRE converter. I found a thread from this list from 2002: http://marc.info/?l=php-internals&m=103625548402350&w=2 Ilia proposed a patch that would replace the ereg library with code that would allow an ereg userland call to be processed with the PCRE library (if I've understood the 2002 post correctly). I'm not complaining about dropping ereg nor taking a position on whether many or few would complain about dropping ereg. I just wanted to point out some past work that might be applicable lest someone start from scratch. BTW, thank you to all who have contributed to php. - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, 12 Oct 2009, Mark Krenz wrote: > Again, this isn't a debate on which is better, I only want to STRONGLY > stress that I think its a big mistake to remove it in 6.0. The ereg library doesn't handle unicode so it can simply not work. > If nobody simply wants to do the work to make sure ereg is ready for PHP > 6 and unicode support, then you are not doing your job. I hate to call > it a job because I'm sure that you all enjoy doing PHP development, but > there are times when you have to bite the bullet and do the hard work > because its your responsibility to do so. Patches welcome. 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] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 1:28 PM, Derick Rethans wrote: > On Mon, 12 Oct 2009, Mark Krenz wrote: > > > Again, this isn't a debate on which is better, I only want to STRONGLY > > stress that I think its a big mistake to remove it in 6.0. > > The ereg library doesn't handle unicode so it can simply not work. > > > If nobody simply wants to do the work to make sure ereg is ready for PHP > > 6 and unicode support, then you are not doing your job. I hate to call > > it a job because I'm sure that you all enjoy doing PHP development, but > > there are times when you have to bite the bullet and do the hard work > > because its your responsibility to do so. > > Patches welcome. > > 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 > > PHP is the most popular web-development language and it would continue to remain in that position for a very long time. I don't think that if ereg is not longer bundled with PHP this will have any effect in the number of PHP users. There exists a very large number of PHP users around the world; however, there is a significantly smaller and more miniscual number of people who actually design and maintain PHP and its extensions. It is important to stress that the PHP language is maintained by VOLUNTEERS who are committed and dedicated to seeing that PHP continues to prosper while maintaining high quality. Change is something that most people struggle with. As Pierre Joye suggested, just because there are lot of people driving clunkers does not mean we have to keep using clunkers. If there exist a faster, better and more efficient alternative, please adapt. Respect is reciprocal; please be nice to these volunteers because not only are you not paying them but no one else is either. Removing ereg from PHP might seem "Cold Turkey" but at this time that is the wiser thing to do. It's time for the clunker to go. -- "Good Enough" is not good enough. To give anything less than your best is to sacrifice the gift. Quality First. Measure Twice. Cut Once.
Re: [PHP-DEV] Why is ereg being deprecated?
Christian Schneider a écrit : Mark Krenz wrote: But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the I guess that's exactly the reason why it is deprecated now: To indicate that preg_* are the way to go. And as far as I know, using ereg_* function is discouraged in the documentation since PHP 4, 10 years ago, no ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 05:12:47PM GMT, Pierre Joye [pierre@gmail.com] said the following: > > Let me use another example to make you understand the situation. > > I bought a car, which is great, I can repair it myself, can drive Car analogies are seldomly an accurate portrayal to the situation. This case is no different. > Please note that I knew for years that I won't find gaz anymore at some point. > > Shorter version: Topics have been discussed to death, move on, nothing to see. Whenever I bring up an issue like this with the PHP devs, I feel like you guys never experience having to support PHP. Among other things, I am the main sysadmin for my web hosting company and have been supporting PHP since version 3 there. When 4.0 came out, I had to help people change their code accordingly to fix any changes and so on with subsequent versions. But I know that a lot of the people who write code in PHP aren't on this mailing list and don't even look at the PHP manual. A lot of causual developers simply copy code from other places. You might say that its their fault for not keeping up with what they are using and properly learning how to use it. I'd probably agree with you. But at the same time, PHP's ease of use has caused this. Its easy for anyone to sit down with no programming experience and figure out how to process a form, often times by downloading someone else's code and modifying it a bit. Then they learn more off of that and before you know it they are writing stock market simulations. I know a few people like this. I'm guilty of this a bit too (although I've read through most of the PHP documentation and a few books too). I wonder how many of the major apps that people use regularly use ereg and their developer don't know about this change. So for the project developers to just say screw you, we're dropping ereg in 6 and you can't do anything about it without giving a chance for that information to make its way downstream is pretty cold and will lead to a lot of angry people that maybe you don't have to deal with, but the rest of us that run servers and maintain code have to deal with. Its easy for you guys on the list to say that you've known about this or that, because you spend most of your time on PHP and are somewhat in your own world. I spend a fair amount of time on PHP and I still didn't know about this change until recently. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Patch: Use notices in PDO
Hi, I'm writing here to take a point about the discussion. On one side, you want to turn this functionality to a global function, like it is describe into this patch and on the other side, you said that on MySQL and Oracle we can get this notices with queries so it is not needed for them but only for PostgreSQL. Before continuing every development I want to make like a survey about what I (or we) will do. Here are my proposals: 1. Make this functionality only for PostgreSQL, with a "pgGetNotices" function. 2. Continue development for MySQL & Oracle, with the known that if notices recuperation is enabled, PDO will have to do queries. 3. Let development at this stage waiting that somebody else propose a notices patch for other Database than PostgreSQL. Note: For MySQL there'is the mysql_info function (http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html) Thanks a lot for your reply. Samuel. Le jeudi 08 octobre 2009 à 23:51 +0200, Samuel ROZE a écrit : > Hi, > > I've make a patch which insert notices concepts to PDO. It create: > - PDO::noticeInfo() - to be like errorInfo > - PDO::ATTR_LOG_NOTICES, the name of the PDO parameter > - PDO::NOTICES_FETCH - fetch notices > - PDO::NOTICES_NONE - don't fetch notices > > The notices HashTable is emptied at each queries. > > There is a patch to implements this function into PDO: > http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patch > > And one other to implements notices recuperation for PostgreSQL: > http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-pgsql-notices-managment.patch > > It can be done for Oracle, i'm sure. > > Thanks for feedbacks. > Samuel. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 05:12:43PM GMT, Christian Schneider [cschn...@cschneid.com] said the following: > Mark Krenz wrote: > > But I'm willing to bet that the majority of people are using ereg, not > > PCRE. I've known about PCRE in PHP for a while now, but I continue to > > use ereg because I thought it had better support in PHP and that it was > > the more "official" function. Guess I was wrong. I'm sure I'm not the > > I guess that's exactly the reason why it is deprecated now: To indicate > that preg_* are the way to go. Uh, really? That's a rather cryptic way of communicating with people. Since ereg was there before preg, a lot of people think that ereg is the more official function. There are plenty of functions that were added into PHP to support lots of different things, I never expected all of them to be well maintained and wondered if I would use some function if eventually it would get removed due to lack of support. preg was kinda like that for me. > As far as I understand ereg will be moved to a PECL-extension to keep it > around for people who can't switch. Then why doesn't it say this anywhere? So long as the PECL ereg is exactly the same, then I guess I don't have a problem. However I still think this is a change that should have been warned about further in advance, people might not have PEAR turned on. Some brain dead webhosts out there just upgrade across major versions of PHP without warning their customers and leave a lot of people's code in broken states. If some major webhost that a lot of sites used did this, you could suddenly find a lot of websites on the Internet not working one day. And I think the blame would partially fall on the PHP devs for not providing enough warning. > > If ereg isn't ready yet then 6.0 should be delayed until it is ready. > > It probably never will be... That's bullshit. Its not like Duke Nukem or something. I've never seen a major version of PHP take more than a couple years to release and PHP 6 seems to be well on its way. I expected it would be released sometime in 2010. > Don't get too worked up on this because (as far as I understand the > messages on internals) PHP 6 will not be a drop-in replacement for PHP > 5.3 anyway. Hosters will have to configure it (like installing the > PECL-extension), developers will have to adapt some code. Major versions of PHP seldom are a drop in replacement. ie, you can't just simply run yum upgrade php and hope for the best, you need to do the extra code migration work. However, removing ereg would probably be the most siginficant changes to PHP ever from a code migration point of view. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Lukas Kahwe Smith wrote: [snip] On 12.10.2009, at 18:57, Mark Krenz wrote: On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com] said the following: [snip] But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the only one who thought this. Maybe try to substantiate that argument with a google code search or something. Personally I have seen quite the opposite, then again I have been actively encouraging people to use preg since about 5 or more years now. Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results Code Search of: "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\( lang:php" shows ~374,000 results Looks like preg_* functions are used more often than ereg* functions to me... Cheers!, -- Carl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Hello, On Mon, Oct 12, 2009 at 10:36 AM, Mark Krenz wrote: > Whenever I bring up an issue like this with the PHP devs, I feel like > you guys never experience having to support PHP. Among other things, I > am the main sysadmin for my web hosting company and have been supporting > PHP since version 3 there. When 4.0 came out, I had to help people > change their code accordingly to fix any changes and so on with > subsequent versions. > .. snip ... > So for the project developers to just say screw you, we're dropping > ereg in 6 and you can't do anything about it without giving a chance for > that information to make its way downstream is pretty cold and will lead > to a lot of angry people that maybe you don't have to deal with, but the > rest of us that run servers and maintain code have to deal with. Just because you did not find the information does not mean it was unavailable. Assuming developers are saying "screw you" is just ignorant. No one says you have to upgrade to PHP6 the moment it is available. you could run PHP5 another 10 years if you choose. If you choose to go through whatever measures you find necessary then no one is at fault except for you. Many web hosting companies waited until after PHP4 was entirely deprecated to upgrade to PHP5, and some, likely still run PHP4 on some servers for customers to stubborn to upgrade. Your assumption of responsibility I find incorrect, your general approach to this discussion I find distasteful. If it bothers you this much put a patch out, that can be discussed and perhaps applied depending on the consensus. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 05:34:08PM GMT, Olivier B. [php-dev.l...@daevel.fr] said the following: > And as far as I know, using ereg_* function is discouraged in the > documentation since PHP 4, 10 years ago, no ? > Discouraged, no. From looking at archive.org, it looks like there has been this note in the ereg docs since 2002: Note: preg_match(), which uses a Perl-compatible regular expression syntax, is often a faster alternative to ereg(). But that is just a note. Its not saying that preg is the best way to go because ereg will be removed. And there is no version of that page on archive.org that contains the deprecation warning. So its newer than June of 2008. I suspect its been in there since mid 2009, which is hardly enough time. You really need to allow time for the change to make its way through all the support channels. PHP is not a small project anymore, but you guys are treating it like one. Books need to be revised to tell people to use preg_match, websites with tutorials need to be updated and so on. You can't just make a change like this overnight and hope that the PECL function will take over. This is what you call alienating your users. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
2009.10.12 19:22 Mark Krenz rašė: > > Just to clarify. You mean that with the changes you've made for > Unicode support in PHP 6, that current POSIX based ereg expressions will > not work the same? Expressions didn't work 1,5 year ago. http://bugs.php.net/bug.php?id=44923 Maybe current PHP6-dev handles test code better, but bug report is still open. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
2009.10.12 20:55 Carl P. Corliss rašė: > Lukas Kahwe Smith wrote: > [snip] > >> On 12.10.2009, at 18:57, Mark Krenz wrote: >> >>> On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye >>> [pierre@gmail.com] said the following: > [snip] > >>> But I'm willing to bet that the majority of people are using ereg, not >>> PCRE. I've known about PCRE in PHP for a while now, but I continue to >>> use ereg because I thought it had better support in PHP and that it was >>> the more "official" function. Guess I was wrong. I'm sure I'm not the >>> only one who thought this. >> >> Maybe try to substantiate that argument with a google code search or >> something. Personally I have seen quite the opposite, then again I have >> been actively encouraging people to use preg since about 5 or more years >> now. > > Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results > Code Search of: > "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\( > lang:php" shows ~374,000 results > > Looks like preg_* functions are used more often than ereg* functions to > me... preg_quote() and preg_last_error() are support functions. They are used together with other pcre functions. You double some search results. If you have to support something, it is not about statistics. Even 1% is important. Before you use statistics against something, remember that statistics can be used against you too. Everyone of us is one in seven billion. Any person is just 0,00014% in Earth statistics. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 19:47, Mark Krenz wrote: If ereg isn't ready yet then 6.0 should be delayed until it is ready. It probably never will be... That's bullshit. Its not like Duke Nukem or something. I've never seen a major version of PHP take more than a couple years to release and PHP 6 seems to be well on its way. I expected it would be released sometime in 2010. Uhm, please keep your language under control. Anyways PHP6 has been delayed quite a few times, which is why PHP 5.3 was released to get a lot of the PHP6 non unicode features into the hands of users earlier. Anyways if at all .. PHP6 will come out late 2010, but I think the first stable release will not come before 2011, meaning that there will be around 2 years between it being marked deprecated in a stable release and it disappearing in the latest stable release. Chances are high that the PHP5 tree will still be actively maintained for a few years there after and that the big libraries will not drop PHP5 support until a few years as well, so for most users they will have about 3-5 years to adapt. The rest are people who want to be on the bleeding edge and those users usually write their own code to be bleeding edge too. So relax and again if you feel that your paying customers will suffer too much, pay someone to write the code. Furthermore, if you care about PHP, you might want to register for a wiki account and write up that summary about this discussion, so that we can spare us starting this discussion at zero again in the future. Thanks and have a nice day. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 05:08:33PM GMT, Lukas Kahwe Smith [...@pooteeweet.org] said the following: > Wow, you sure do assume a lot of things about PHP and its development > community. I have never seen your name on this list before and (now I > am assuming) do not know the state of development of PHP6 (as in that > its more or less on halt until someone gets things going again). I've never seen your name before, but I've been using PHP for a while. In other words, there are lots of people involved and affected by this, far more than any of you seem to realize as indicated by your comments. > Maybe try to substantiate that argument with a google code search or > something. Personally I have seen quite the opposite, then again I > have been actively encouraging people to use preg since about 5 or > more years now. Been using PHP since 1997 (version 2). Been a sysadmin at 3 places that all have some PHP use, have been a paid developer on a major PHP based project that I didn't even write, but contained over 130,000 lines of PHP code. Written by someone with more experience than me. I've looked at and even modified PHP code for countless open source projects. I've read books and lots of documentation on PHP. Of all that, I have seen very little use of the preg functions. Some people use it sure, but it is by no means the standard. And obviously from what other people are doing, I'm not alone. Its you guys that are in the minority here. > Well the whole internet hasnt setup a donation box to pay for > developers to work on stuff like this full time. Heh, Its not the job of the internet to take donations, that's the job of the people running the PHP project, but I don't see any mention of donate on the PHP website. It always seemed from the outside like Zend somewhat supported the project. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 20:34, Tomas Kuliavas wrote: 2009.10.12 20:55 Carl P. Corliss rašė: Lukas Kahwe Smith wrote: [snip] On 12.10.2009, at 18:57, Mark Krenz wrote: On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com] said the following: [snip] But I'm willing to bet that the majority of people are using ereg, not PCRE. I've known about PCRE in PHP for a while now, but I continue to use ereg because I thought it had better support in PHP and that it was the more "official" function. Guess I was wrong. I'm sure I'm not the only one who thought this. Maybe try to substantiate that argument with a google code search or something. Personally I have seen quite the opposite, then again I have been actively encouraging people to use preg since about 5 or more years now. Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results Code Search of: "preg_(filter|grep|last_error|match_all|match|quote| replace_callback|replace|split)\( lang:php" shows ~374,000 results Looks like preg_* functions are used more often than ereg* functions to me... preg_quote() and preg_last_error() are support functions. They are used together with other pcre functions. You double some search results. If you have to support something, it is not about statistics. Even 1% is important. Before you use statistics against something, remember that statistics can be used against you too. Everyone of us is one in seven billion. Any person is just 0,00014% in Earth statistics. Puh, I think this was a valid attempt at putting things closer to numbers rather then assumptions. Mark's claim was that ereg is being used more than preg and I think these stats do put some doubt on that claim, even though it should also be noted that there are several ereg using functions that are not prefixed with ereg. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 19:08, Lukas Kahwe Smith wrote: > Well again an assumption .. no we do not have enough developers to do all > the cool things we can think up and still fix bugs, document stuff etc. Feel Shameless plug; http://joind.in/talk/view/971 ! Now, go vote for it so I can do some recruitment at Zendcon! -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
[Please stop feeding the troll.] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Tomas Kuliavas wrote: [snip] Looks like preg_* functions are used more often than ereg* functions to me... preg_quote() and preg_last_error() are support functions. They are used together with other pcre functions. You double some search results. Actually, searching for those by themselves shows only about 24K worth of results - a far cry from doubling anything. Even adding /spliti?/ for ereg results only increases it to around ~170K results. If you have to support something, it is not about statistics. Even 1% is important. Before you use statistics against something, remember that statistics can be used against you too. Everyone of us is one in seven billion. Any person is just 0,00014% in Earth statistics. Sure, it's not empirical data, however it's certainly useful as a means for gauging (albeit roughly) the use of ereg* functions. Regardless, we could really argue statistics all day if we wanted but, that would be beside the point - which is that ereg* functions are, like it or not, deprecated. Not that I mind given the fact that the preg* functions are typically faster anyway. -- Carl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [patch] bug 45808
Hi everyone, I have made a patch to fix this bug: http://bugs.php.net/bug.php?id=45808 Diff against 5.3.0 is here: http://si.kz/php-bug-45808.diff.txt As far as I have tested, everything works as expected with this patch applied. Can someone with karma please review it and apply to HEAD and/or 5.3 branch ? Regards, Vincent -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com] said the following: > > Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results > Code Search of: > "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\( > > lang:php" shows ~374,000 results > > Looks like preg_* functions are used more often than ereg* functions to > me... I think everyone should read this as it will prove my point. Especially book #9 I have a O'Reilly Safari Books Online account and can search the content of many of the latest books, which I consider something more official than just doing a causual Google search, which can be misleading. The number 1 selling book on Amazon in the PHP category is "PHP and MySQL Web Development" (4th Edition) from 2008 by Luke Welling and Laura Thomson. There is no mention of preg_match and the book instead shows how to use ereg based functions. In fact, they do mention PCRE, but downplay it by saying that POSIX regexs are easier to use. I think any intelligent person would see this as a alarm that the PHP world isn't ready for ereg to be dropped or changed. You need far more time for the information to make its way through the PHP community. Going further through the list of Amazon's top selling PHP books we have: 2. The Essential Guide to Dreamweaver CS4 with CSS, Ajax, and PHP (Essentials) Ignore this as it isn't really covering PHP properly. 3. Regular Expression Pocket Reference: Regular Expressions: from 2008 This states that it covered PCRE expressions for PHP. So at least that's right. 4. Learning PHP, MySQL, and JavaScript: A Step-by-Step Guide to Creating Dynamic Websites from 2009 Uses examples written with preg_match 5. Web Database Applications with PHP and MySQL, 2nd Edition from 2004. Mentions PCRE but says that they will use POSIX expressions instead. 6. Head First PHP & MySQL from 2008/2009 Talks about preg_match, mentions that ereg is removed in PHP 6. 7. PHP Cookbook from 2006 Has mixed examples, some using ereg and some using preg_match 8. Practical WebPractical Web 2.0 Applications with PHP Not on Safari > 9. Programming PHP by Kevin Tatroe, Rasmus Lerdorf and Peter MacIntyre in 2006. Which may be considered the definitive guide to PHP since Rasmus is a co-author. Uses examples with both ereg and preg_match, BUT ereg is used first in the book and compromises the majority of the section called "Regular Expressions". So here is an example of emphasis being placed on ereg being the more official functions to use. 10. Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems Not on Safari So that's about 4 out of 7 the top selling books on PHP still strongly use ereg. I didn't find any mention in the books I read online about ereg going away. Some of them supported PCRE more than others. But obviously there is still a lot of use of the POSIX functions. These are best selling books on PHP. So there ARE A LOT of programmers out there that think that they are doing the right thing using ereg. Obviously books can't be the authoritative source for functions, but a lot of times they are used that way, especially when one of them was written by the author of the language. Duh! So there is my proof. Does anyone still want to dispute me that ereg is still heavily used and you'll make a lot of users angry if you don't give them the proper amount of time to make this transition? -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Mark Krenz wrote: On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com] said the following: Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results Code Search of: "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\( lang:php" shows ~374,000 results Looks like preg_* functions are used more often than ereg* functions to me... I think everyone should read this as it will prove my point. Especially book #9 I have a O'Reilly Safari Books Online account and can search the content of many of the latest books, which I consider something more official than just doing a causual Google search, which can be misleading. The number 1 selling book on Amazon in the PHP category is "PHP and MySQL Web Development" (4th Edition) from 2008 by Luke Welling and Laura Thomson. There is no mention of preg_match and the book instead shows how to use ereg based functions. In fact, they do mention PCRE, but downplay it by saying that POSIX regexs are easier to use. I think any intelligent person would see this as a alarm that the PHP world isn't ready for ereg to be dropped or changed. You need far more time for the information to make its way through the PHP community. You are obviously right of course... the PHP world is NOT ready for the POSIX regex library to be dropped. That's why it's "deprecated" in PHP 5.3 and not removed. In a year or 3, when PHP 6 is released, one would hope that by then the PHP world WILL be ready. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] bug 45808
hi, Can you add the link to the bug itself please? We won't loose it thebn :) Thanks for your work, On Mon, Oct 12, 2009 at 8:55 PM, Vincent NEGRIER wrote: > Hi everyone, > > I have made a patch to fix this bug: http://bugs.php.net/bug.php?id=45808 > > Diff against 5.3.0 is here: http://si.kz/php-bug-45808.diff.txt > > As far as I have tested, everything works as expected with this patch > applied. Can someone with karma please review it and apply to HEAD and/or > 5.3 branch ? > > Regards, > Vincent > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- 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] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 06:34:02PM GMT, Tomas Kuliavas [to...@users.sourceforge.net] said the following: > > preg_quote() and preg_last_error() are support functions. They are used > together with other pcre functions. You double some search results. > > If you have to support something, it is not about statistics. Even 1% is > important. Before you use statistics against something, remember that > statistics can be used against you too. Everyone of us is one in seven > billion. Any person is just 0,00014% in Earth statistics. > Thank you Tomas, of all the posts replying to me so far, this one supports my point the most, even if its not meant too. There are only so many people on the PHP-DEV list and obviously you guys know what you are doing with PHP, but that leaves out pretty much all the people that use it. I'm trying to represent those people and voice our opinion. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 3:14 PM, Mark Krenz wrote: > On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com] > said the following: > > > > Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results > > Code Search of: > > > "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\( > > lang:php" shows ~374,000 results > > > > Looks like preg_* functions are used more often than ereg* functions to > > me... > > I think everyone should read this as it will prove my point. > Especially book #9 > > I have a O'Reilly Safari Books Online account and can search the > content of many of the latest books, which I consider something more > official than just doing a causual Google search, which can be > misleading. > > The number 1 selling book on Amazon in the PHP category is "PHP and > MySQL Web Development" (4th Edition) from 2008 by Luke Welling and > Laura Thomson. > > There is no mention of preg_match and the book instead shows how to > use ereg based functions. In fact, they do mention PCRE, but downplay > it by saying that POSIX regexs are easier to use. > > > I think any intelligent person would see this as a alarm that the PHP > world isn't ready for ereg to be dropped or changed. You need far more > time for the information to make its way through the PHP community. > > > Going further through the list of Amazon's top selling PHP books we > have: > > 2. The Essential Guide to Dreamweaver CS4 with CSS, Ajax, and PHP > (Essentials) > > Ignore this as it isn't really covering PHP properly. > > 3. Regular Expression Pocket Reference: Regular Expressions: from 2008 > > This states that it covered PCRE expressions for PHP. So at least > that's right. > > > 4. Learning PHP, MySQL, and JavaScript: A Step-by-Step Guide to Creating > Dynamic Websites from 2009 > > Uses examples written with preg_match > > 5. Web Database Applications with PHP and MySQL, 2nd Edition from 2004. > > Mentions PCRE but says that they will use POSIX expressions instead. > > 6. Head First PHP & MySQL from 2008/2009 > > Talks about preg_match, mentions that ereg is removed in PHP 6. > > 7. PHP Cookbook from 2006 > > Has mixed examples, some using ereg and some using preg_match > > 8. Practical WebPractical Web 2.0 Applications with PHP > > Not on Safari > > > 9. Programming PHP by Kevin Tatroe, Rasmus Lerdorf and Peter > MacIntyre in 2006. Which may be considered the definitive guide to PHP > since Rasmus is a co-author. > > Uses examples with both ereg and preg_match, BUT ereg is used first in > the book and compromises the majority of the section called "Regular > Expressions". So here is an example of emphasis being placed on ereg > being the more official functions to use. > > 10. Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems > > Not on Safari > > So that's about 4 out of 7 the top selling books on PHP still strongly > use ereg. I didn't find any mention in the books I read online about > ereg going away. Some of them supported PCRE more than others. But > obviously there is still a lot of use of the POSIX functions. > > These are best selling books on PHP. So there ARE A LOT of programmers > out there that think that they are doing the right thing using ereg. > Obviously books can't be the authoritative source for functions, but a > lot of times they are used that way, especially when one of them was > written by the author of the language. Duh! > > > So there is my proof. Does anyone still want to dispute me that ereg is > still heavily used and you'll make a lot of users angry if you don't > give them the proper amount of time to make this transition? > > > > > -- > Mark S. Krenz > IT Director > Suso Technology Services, Inc. > http://suso.org/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > If you are feeling this strongly about ereg, I would suggest you do one of the following: 1. Create a patch that contains a re-write and submit it for discussion to the internals mailing list. 2. If you are unable to do # 1. Hire or get a volunteer who can and is willing to create the patch for you. This will save us a lot of time and energy that is being dissipated/wasted in this discussion. You can also document the issue in the wiki to warn userspace PHP developers about the current situation. Again, please note that PHP is designed, developed and maintained by VOLUNTEERS. Please treat these volunteers with respect. -- "Good Enough" is not good enough. To give anything less than your best is to sacrifice the gift. Quality First. Measure Twice. Cut Once.
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 8:14 PM, Mark Krenz wrote: > So there is my proof. Does anyone still want to dispute me that ereg is > still heavily used and you'll make a lot of users angry if you don't > give them the proper amount of time to make this transition? > Hello Mark Krenz, please take the following steps: 1) Stop posting pointless junk to the lists as you are alienating all the developers that could possibly help you in the future 2) Create a proper technical proposal on how to solve the Unicode issues in ext/ereg. 3) Get someone to implement your proposal. Nothing helps your cause like a proper patch. Regards, Mikko -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Hello everyone, Let's create a guide for people wanting to convert code from ereg to preg. Please post a few items that belong like: 1. Delimiters are needed with PCRE 2. /i versus eregi 3. Something needed to be said about named classes? What else? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Write yourself a bit of code that replaces ereg which could be installed in an auto_prepend location server-wide. Here's an example you could start with, although I should point out that I spent all of about 30 seconds thinking about it, so you might want to give it more thought than that - I'm sure there are some funny edge cases in the way people have relied on ereg behaviour, but you'd be more likely to know that than I since I haven't used ereg() since the day PCRE support was added to PHP. if (! function_exists('ereg')) { function ereg($pattern, $string, &$regs = array()) { $matches = array(); $delimiters = array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/', '@', '#', '%', '_'); foreach($delimiters as $c) { if (strpos($string, $c) !== FALSE) continue; $d = $c; } if (preg_match_all($d.$pattern.$d, $string, $matches)) return strlen($string); return false; } } Much the same could be done for split(), ereg_replace(), and so on. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On 12.10.2009, at 21:48, Joey Smith wrote: Write yourself a bit of code that replaces ereg which could be installed in an auto_prepend location server-wide. Here's an example you could start with, although I should point out that I spent all of about 30 seconds thinking about it, so you might want to give it more thought than that - I'm sure there are some funny edge cases in the way people have relied on ereg behaviour, but you'd be more likely to know that than I since I haven't used ereg() since the day PCRE support was added to PHP. if (! function_exists('ereg')) { function ereg($pattern, $string, &$regs = array()) { $matches = array(); $delimiters = array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/', '@', '#', '%', '_'); foreach($delimiters as $c) { if (strpos($string, $c) !== FALSE) continue; $d = $c; } if (preg_match_all($d.$pattern.$d, $string, $matches)) return strlen($string); return false; } } Much the same could be done for split(), ereg_replace(), and so on. Feel free to collaborate with the authors of PHP_Compat [1]. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] http://pear.php.net/package/PHP_Compat -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Ooops: On Mon, Oct 12, 2009 at 01:48:28PM -0600, Joey Smith wrote: > $delimiters = > array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/', '@', '#', '%', '_'); should have been $delimiters = array(chr(1),chr(2),chr(3),chr(4),chr(5),chr(6),'/', '@', '#', '%', '_'); I used these because given the feature-set of ereg, it seems unlikely that people were passing binary strings into ereg() today, but again - the people who *use* ereg should give it some thought. I'm confident there's a simple path forward for you just by providing the function in "userland" if you do so. -- 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
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
Re: [PHP-DEV] Why is ereg being deprecated?
> Feel free to collaborate with the authors of PHP_Compat [1]. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > [1] http://pear.php.net/package/PHP_Compat An excellent pointer, Lukas, thank you. I had forgotten PHP_Compat existed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings [rob...@interjinn.com] said the following: > > You are obviously right of course... the PHP world is NOT ready for the > POSIX regex library to be dropped. That's why it's "deprecated" in PHP > 5.3 and not removed. In a year or 3, when PHP 6 is released, one would > hope that by then the PHP world WILL be ready. > One would hope, but I've seen otherwise over the past 10 or 11 years of administrating PHP. Often times the latest supported versions of operating systems do not contain a version of PHP that is recent or supported even. And typically people will run a server for around 3-5 years so they end up having a version of PHP that is way behind. PHP Developers may wonder about this but it is completely acceptable and expected from a sysadmin point of view. I know that I never feel like I'm on a supported version of PHP, even though I'll use a recent OS version. So what happens is if its timed right, many people will never be running PHP 5.3 and will end up straight on PHP 6. I used the term overnight before and I think that confused people. What I mean is overnight in terms of version numbers. For instance, overnight would be like one patch level or even minor version to the next. When a function is deprecated, I expect to see the warning for quite a while before its actually removed. So if it just happens "overnight" thats not acceptable, no matter how much time has passed. Its more about version numbers than time. -- Mark S. Krenz IT Director Suso Technology Services, Inc. http://suso.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz wrote: > On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings > [rob...@interjinn.com] said the following: >> >> You are obviously right of course... the PHP world is NOT ready for the >> POSIX regex library to be dropped. That's why it's "deprecated" in PHP >> 5.3 and not removed. In a year or 3, when PHP 6 is released, one would >> hope that by then the PHP world WILL be ready. >> > > One would hope, but I've seen otherwise over the past 10 or 11 years > of administrating PHP. > You are just the one in seven billion. > Often times the latest supported versions of operating systems do not > contain a version of PHP that is recent or supported even. And > typically people will run a server for around 3-5 years so they end up > having a version of PHP that is way behind. PHP Developers may wonder > about this but it is completely acceptable and expected from a sysadmin > point of view. I know that I never feel like I'm on a supported > version of PHP, even though I'll use a recent OS version. Major versions can and will break backward compatibility. If your code does not ready for php6, then you have 3-10 years to port it to the php6. If you dont want to, then its fine, you dont have to. > > So what happens is if its timed right, many people will never be > running PHP 5.3 and will end up straight on PHP 6. > Why would somebody skip php 5.3 when porting the applications from 5.2 is easy, then switch to php6 to its release day? > I used the term overnight before and I think that confused people. > What I mean is overnight in terms of version numbers. For instance, > overnight would be like one patch level or even minor version to the > next. > > When a function is deprecated, I expect to see the warning for quite a > while before its actually removed. So if it just happens "overnight" > thats not acceptable, no matter how much time has passed. Its more > about version numbers than time. > If -at least- 3 years of warning is overnight for you, than I think I'm lucky to catch you awake. > > -- > Mark S. Krenz > IT Director > Suso Technology Services, Inc. > http://suso.org/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I don't like the way that you say you are representing "the whole internet", it would be better if we can go for the one person one vote rule. Sorry for my english, I'm not a native speaker, and it's getting late. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs wrote: > On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz wrote: >> On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings >> [rob...@interjinn.com] said the following: >>> >>> You are obviously right of course... the PHP world is NOT ready for the >>> POSIX regex library to be dropped. That's why it's "deprecated" in PHP >>> 5.3 and not removed. In a year or 3, when PHP 6 is released, one would >>> hope that by then the PHP world WILL be ready. >>> >> >> One would hope, but I've seen otherwise over the past 10 or 11 years >> of administrating PHP. >> > You are just the one in seven billion. >> Often times the latest supported versions of operating systems do not >> contain a version of PHP that is recent or supported even. And >> typically people will run a server for around 3-5 years so they end up >> having a version of PHP that is way behind. PHP Developers may wonder >> about this but it is completely acceptable and expected from a sysadmin >> point of view. I know that I never feel like I'm on a supported >> version of PHP, even though I'll use a recent OS version. > Major versions can and will break backward compatibility. > If your code does not ready for php6, then you have 3-10 years to port > it to the php6. > If you dont want to, then its fine, you dont have to. >> >> So what happens is if its timed right, many people will never be >> running PHP 5.3 and will end up straight on PHP 6. >> > Why would somebody skip php 5.3 when porting the applications from 5.2 > is easy, then switch to php6 to its release day? >> I used the term overnight before and I think that confused people. >> What I mean is overnight in terms of version numbers. For instance, >> overnight would be like one patch level or even minor version to the >> next. >> >> When a function is deprecated, I expect to see the warning for quite a >> while before its actually removed. So if it just happens "overnight" >> thats not acceptable, no matter how much time has passed. Its more >> about version numbers than time. >> > If -at least- 3 years of warning is overnight for you, than I think > I'm lucky to catch you awake. >> >> -- >> Mark S. Krenz >> IT Director >> Suso Technology Services, Inc. >> http://suso.org/ >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > I don't like the way that you say you are representing "the whole > internet", it would be better if we can go for the one person one vote > rule. > > Sorry for my english, I'm not a native speaker, and it's getting late. > > Tyrael > btw. I hate php 5.3 for the following change: # The use of {} to access string offsets is deprecated. Use [] instead. I always used the {} because the [] was deprecated for a long time, and I corrected everybody, to use the {}, and in one release, the [] gets undeprecated, and the {} to deprecated. Shame on you people, but I think I have to live with it. :) Tyrael -- 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
hi Samuel, May I ask you to do it in the wiki? We have a dedicated section there: http://wiki.php.net/RFC Cheers, On Mon, Oct 12, 2009 at 10:13 PM, Samuel ROZE wrote: > 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 > > -- 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] Why is ereg being deprecated?
Mark, You contradict yourself. You say that putting a warning in 5.3 isn't soon enough, since most people are a few versions behind. Yet you think it is an absolute outrage that something is being dropped in 6, which is a couple of years away anyway. The people that won't be on 5.3 in time to be notified of the change won't be upgrading to 6 for a year or two after the release anyway. If people are upgrading as new versions are marked stable, they've already seen the warnings. If they aren't, then there will be a ton of time for them to port their code to use PCRE before they get anywhere near installing 6. Besides, any time you upgrade to a major revision, you should basically expect your code to break. Since it's been pointed out that ereg will be moved to a PECL extension, hosting providers who have users that depend on ereg will be able to just install the extension. CRISIS AVERTED! And in the meantime, you've insulted the core PHP developers and have made a big stink, when really, they're just trying to make the best decision for moving the language along. Good going. Unicode support is far more important than posix regex support. If you feel so strongly about keeping ereg, you should do the work required to keep it instead of pissing and moaning at others for not doing it, while making accusatory statements at people who donate their time to work on an open source project. Cheers, Mike. On Mon, Oct 12, 2009 at 2:57 PM, Ferenc Kovacs wrote: > On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs wrote: > > On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz wrote: > >> On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings [ > rob...@interjinn.com] said the following: > >>> > >>> You are obviously right of course... the PHP world is NOT ready for the > >>> POSIX regex library to be dropped. That's why it's "deprecated" in PHP > >>> 5.3 and not removed. In a year or 3, when PHP 6 is released, one would > >>> hope that by then the PHP world WILL be ready. > >>> > >> > >> One would hope, but I've seen otherwise over the past 10 or 11 years > >> of administrating PHP. > >> > > You are just the one in seven billion. > >> Often times the latest supported versions of operating systems do not > >> contain a version of PHP that is recent or supported even. And > >> typically people will run a server for around 3-5 years so they end up > >> having a version of PHP that is way behind. PHP Developers may wonder > >> about this but it is completely acceptable and expected from a sysadmin > >> point of view. I know that I never feel like I'm on a supported > >> version of PHP, even though I'll use a recent OS version. > > Major versions can and will break backward compatibility. > > If your code does not ready for php6, then you have 3-10 years to port > > it to the php6. > > If you dont want to, then its fine, you dont have to. > >> > >> So what happens is if its timed right, many people will never be > >> running PHP 5.3 and will end up straight on PHP 6. > >> > > Why would somebody skip php 5.3 when porting the applications from 5.2 > > is easy, then switch to php6 to its release day? > >> I used the term overnight before and I think that confused people. > >> What I mean is overnight in terms of version numbers. For instance, > >> overnight would be like one patch level or even minor version to the > >> next. > >> > >> When a function is deprecated, I expect to see the warning for quite a > >> while before its actually removed. So if it just happens "overnight" > >> thats not acceptable, no matter how much time has passed. Its more > >> about version numbers than time. > >> > > If -at least- 3 years of warning is overnight for you, than I think > > I'm lucky to catch you awake. > >> > >> -- > >> Mark S. Krenz > >> IT Director > >> Suso Technology Services, Inc. > >> http://suso.org/ > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > I don't like the way that you say you are representing "the whole > > internet", it would be better if we can go for the one person one vote > > rule. > > > > Sorry for my english, I'm not a native speaker, and it's getting late. > > > > Tyrael > > > > btw. I hate php 5.3 for the following change: > # The use of {} to access string offsets is deprecated. Use [] instead. > I always used the {} because the [] was deprecated for a long time, > and I corrected everybody, to use the {}, and in one release, the [] > gets undeprecated, and the {} to deprecated. > Shame on you people, but I think I have to live with it. :) > > Tyrael > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Why is ereg being deprecated?
Mark Krenz wrote: > On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com] said the following: > >> Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results >> Code Search of: "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\( lang:php" shows ~374,000 results >> >> Looks like preg_* functions are used more often than ereg* functions to me... >> > > I think everyone should read this as it will prove my point. > Especially book #9 > > I have a O'Reilly Safari Books Online account and can search the > content of many of the latest books, which I consider something more > official than just doing a causual Google search, which can be > misleading. > > The number 1 selling book on Amazon in the PHP category is "PHP and > MySQL Web Development" (4th Edition) from 2008 by Luke Welling and > Laura Thomson. > > There is no mention of preg_match and the book instead shows how to > use ereg based functions. In fact, they do mention PCRE, but downplay > it by saying that POSIX regexs are easier to use. > > > I think any intelligent person would see this as a alarm that the PHP > world isn't ready for ereg to be dropped or changed. You need far more > time for the information to make its way through the PHP community. > > > Going further through the list of Amazon's top selling PHP books we > have: > > 2. The Essential Guide to Dreamweaver CS4 with CSS, Ajax, and PHP (Essentials) > > Ignore this as it isn't really covering PHP properly. > 3. Regular Expression Pocket Reference: Regular Expressions: from 2008 > > This states that it covered PCRE expressions for PHP. So at least > that's right. > > > 4. Learning PHP, MySQL, and JavaScript: A Step-by-Step Guide to Creating > Dynamic Websites from 2009 > > Uses examples written with preg_match > > 5. Web Database Applications with PHP and MySQL, 2nd Edition from 2004. > > Mentions PCRE but says that they will use POSIX expressions instead. > > 6. Head First PHP & MySQL from 2008/2009 > > Talks about preg_match, mentions that ereg is removed in PHP 6. > > 7. PHP Cookbook from 2006 > > Has mixed examples, some using ereg and some using preg_match > > 8. Practical Web Practical Web 2.0 Applications with PHP > > Not on Safari > > > 9. Programming PHP by Kevin Tatroe, Rasmus Lerdorf and Peter > MacIntyre in 2006. Which may be considered the definitive guide to PHP > since Rasmus is a co-author. > > Uses examples with both ereg and preg_match, BUT ereg is used first in > the book and compromises the majority of the section called "Regular > Expressions". So here is an example of emphasis being placed on ereg > being the more official functions to use. > > 10. Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems > > Not on Safari > > So that's about 4 out of 7 the top selling books on PHP still strongly > use ereg. I didn't find any mention in the books I read online about > ereg going away. Some of them supported PCRE more than others. But > obviously there is still a lot of use of the POSIX functions. > 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. Practical Web 2.0 Applications with PHP, published in 2008, uses PCRE functions. Wicked Cool PHP, published in 2008, uses the PCRE functions. The book PHP & MySQL Web Development For Dummies, published in 2008, uses only PCRE funcitons. Doesn't even mention ereg. PHP & MySQL for Dummies sells pretty well. Its fourth edition will be released next month. It uses only PCRE, does not mention ereg. So, it appears that around 2007 most authors recognized that they needed to begin moving readers to the PCRE functions. Janet > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Ferenc Kovacs wrote: On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs wrote: btw. I hate php 5.3 for the following change: # The use of {} to access string offsets is deprecated. Use [] instead. I always used the {} because the [] was deprecated for a long time, and I corrected everybody, to use the {}, and in one release, the [] gets undeprecated, and the {} to deprecated. Shame on you people, but I think I have to live with it. :) I hope you don't mind if I laugh at you and with you... I did exactly the same thing :) I remember about 5 years ago (or whenever it was) changing all my string offset code to use curly braces and then preaching the one true way *meh* :D Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php