[PHP-DEV] PHP 5 Bug Summary Report

2009-10-12 Thread internals
 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 API 

Re: [PHP-DEV] Re: Patch: Use notices in PDO

2009-10-12 Thread Matteo Beccati
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

2009-10-12 Thread internals
 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]
48601 

Re: [PHP-DEV] Re: Patch: Use notices in PDO

2009-10-12 Thread Pierre Joye
hi,

On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati p...@beccati.com 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

2009-10-12 Thread Johannes Schlüter
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

2009-10-12 Thread Johannes Schlüter
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

2009-10-12 Thread Johannes Schlüter
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

2009-10-12 Thread Rune Kaagaard
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

2009-10-12 Thread Lukas Kahwe Smith


On 12.10.2009, at 12:07, Pierre Joye wrote:


hi,

On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati p...@beccati.com  
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



Re: [PHP-DEV] [patch] mysql_warning_count() for ext/mysql

2009-10-12 Thread Ulf Wendel

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?

2009-10-12 Thread Mark Krenz

  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?

2009-10-12 Thread Guilherme Blanco
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 m...@suso.org 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?

2009-10-12 Thread Rasmus Lerdorf
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 m...@suso.org 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?

2009-10-12 Thread Robert Cummings

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 m...@suso.org 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?

2009-10-12 Thread Mark Krenz

  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 m...@suso.org 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?

2009-10-12 Thread Rasmus Lerdorf
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 m...@suso.org 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?

2009-10-12 Thread Mark Krenz

  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 m...@suso.org 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?

2009-10-12 Thread Pierre Joye
hi,

On Mon, Oct 12, 2009 at 6:22 PM, Mark Krenz m...@suso.org 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

2009-10-12 Thread Samuel ROZE
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 Thread Pierre Joye
2009/10/12 Samuel ROZE samuel.r...@gmail.com:
 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?

2009-10-12 Thread Mark Krenz
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?

2009-10-12 Thread Lukas Kahwe Smith
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

2009-10-12 Thread Lukas Kahwe Smith


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?

2009-10-12 Thread Christian Schneider
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?

2009-10-12 Thread Pierre Joye
On Mon, Oct 12, 2009 at 6:57 PM, Mark Krenz m...@suso.org 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?

2009-10-12 Thread Lukas Kahwe Smith


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?

2009-10-12 Thread Todd Ruth
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-internalsm=103625548402350w=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?

2009-10-12 Thread Derick Rethans
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?

2009-10-12 Thread Israel Ekpo
On Mon, Oct 12, 2009 at 1:28 PM, Derick Rethans der...@php.net 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?

2009-10-12 Thread Olivier B.

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?

2009-10-12 Thread Mark Krenz
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

2009-10-12 Thread Samuel ROZE
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?

2009-10-12 Thread Mark Krenz
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?

2009-10-12 Thread Carl P. Corliss

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?

2009-10-12 Thread Chris Stockton
Hello,

On Mon, Oct 12, 2009 at 10:36 AM, Mark Krenz m...@suso.org 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?

2009-10-12 Thread Mark Krenz
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 Thread Tomas Kuliavas
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 Thread Tomas Kuliavas
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?

2009-10-12 Thread Lukas Kahwe Smith


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?

2009-10-12 Thread Mark Krenz
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?

2009-10-12 Thread Lukas Kahwe Smith


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?

2009-10-12 Thread Hannes Magnusson
On Mon, Oct 12, 2009 at 19:08, Lukas Kahwe Smith m...@pooteeweet.org 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?

2009-10-12 Thread Derick Rethans
[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?

2009-10-12 Thread Carl P. Corliss

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

2009-10-12 Thread Vincent NEGRIER

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?

2009-10-12 Thread Mark Krenz
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?

2009-10-12 Thread Robert Cummings

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

2009-10-12 Thread Pierre Joye
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 vinc...@optilian.com 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?

2009-10-12 Thread Mark Krenz
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?

2009-10-12 Thread Israel Ekpo
On Mon, Oct 12, 2009 at 3:14 PM, Mark Krenz m...@suso.org 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?

2009-10-12 Thread Mikko Koppanen
On Mon, Oct 12, 2009 at 8:14 PM, Mark Krenz m...@suso.org 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?

2009-10-12 Thread Philip Olson


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?

2009-10-12 Thread Joey Smith
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?

2009-10-12 Thread Lukas Kahwe Smith


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?

2009-10-12 Thread Joey Smith
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

2009-10-12 Thread Samuel ROZE
Here is what I expect for the notices fetching in PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdf

Samuel.

Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit :
[...]
 
 well .. what Pierre (and me supporting him) was asking for is to  
 create an RFC page that details the actual sticking points with this  
 feature so that they can then discuss the above points more if need  
 be .. or we can take a vote on how to proceed. You are asking the  
 general community to vote on something where there is no clear  
 document describing the state of the discussion. Remember not  
 everybody reads all messages and even I am likely to have forgotten a  
 point raised in this thread by now .. and I have payed attention to  
 this thread from the very beginning. Writing an RFC is not about  
 making your life miserable .. and its not about stalling your request  
 either.
 
 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org
 
 
 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Why is ereg being deprecated?

2009-10-12 Thread Joey Smith
 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?

2009-10-12 Thread Mark Krenz
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?

2009-10-12 Thread Ferenc Kovacs
On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz m...@suso.org 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?

2009-10-12 Thread Ferenc Kovacs
On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs i...@tyrael.hu wrote:
 On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz m...@suso.org 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

2009-10-12 Thread Pierre Joye
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 samuel.r...@gmail.com 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?

2009-10-12 Thread Mike Panchenko
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 i...@tyrael.hu wrote:

 On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs i...@tyrael.hu wrote:
  On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz m...@suso.org 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?

2009-10-12 Thread jval...@eoni.com
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?

2009-10-12 Thread Robert Cummings

Ferenc Kovacs wrote:

On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs i...@tyrael.hu 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