Re: [PHP-DEV] quick polls for 5.3
On 12.11.2008, at 20:14, Lukas Kahwe Smith wrote: 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default +1 II) remove ext/mhash +1 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) c) Document as is +1 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default -1 II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -1 (unless enough people step up) 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) b) MFH to 5.3 +1 regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 20:14, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > Hi, > > here are a few questions that need to be answered ASAP. > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is C > 4) keep ext/phar enabled by default in 5.3? -1 > 5) keep ext/sqlite3 enabled by default in 5.3? +0 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case -0 > 7) should Output buffering rewrite MFH? this one comes with some baggage, we +1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 Wait, what? Didn't even know there was a difference. If there is, B. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Nov 12, 2008, at 1:14 PM, Lukas Kahwe Smith wrote: Hi, here are a few questions that need to be answered ASAP. If at all possible keep your votes as short as possible. I think all of the above topics have been discussed quite a lot on the list. So I hope voters can spare the list needless repetition. Instead if you think that a topic needs to be discussed, put a short note in your vote under the given topic. If a number of people also think the topic needs more discussion, then we can open a new thread dedicated to this topic later this week. 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default II) remove ext/mhash +1 for both 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) b) Should we instead just throw an E_STRICT c) Document as is -1, keep as is 4) keep ext/phar enabled by default in 5.3? -1 5) keep ext/sqlite3 enabled by default in 5.3? -1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1 to both 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. no opinion 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 +1 to B regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, 12 Nov 2008, Lukas Kahwe Smith wrote: > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default > II) remove ext/mhash yes, yes > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is > more or less redundant with ext/preg and is likely to not get much unicode > love for PHP 6, the question is if we should mark it with a E_DEPRECATED in > PHP 5.3 no > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is c > 4) keep ext/phar enabled by default in 5.3? yes > 5) keep ext/sqlite3 enabled by default in 5.3? yes > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be > no external dependencies in this case no, no > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and make > it clear that they will be available for bug fixing and BC issues resolving. > the risk here is obviously that any BC issues will be hard to isolate for end > users. > > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either > (choose one) > a) revert in HEAD > b) MFH to 5.3 a - definitely not b - there is not enough test cases, and there are way too many changes to see what was changed. From what I can see now, allowing this enormous big patch into HEAD was also a bad idea. (And seriously, this shouldn't have been on your list IMO). Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi, Am Mittwoch, den 12.11.2008, 20:14 +0100 schrieb Lukas Kahwe Smith: [...] > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > break will be that "if (extension_loaded('mhash'))" will need fixing > if mhash is removed (answer both) > I) enable ext/hash by default > II) remove ext/mhash yes, yes. Probably hack ZEND_FUNCTION(extension_loaded) to return true when "mhash" is passed and throw a deprecation warning. Is pretty easy but ugly. What would our ZE guys suggest to accomplish something like that? > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ > ereg is more or less redundant with ext/preg and is likely to not get > much unicode love for PHP 6, the question is if we should mark it with > a E_DEPRECATED in PHP 5.3 yes > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate > STDIN and friends) > b) Should we instead just throw an E_STRICT > c) Document as is c > 4) keep ext/phar enabled by default in 5.3? yes > 5) keep ext/sqlite3 enabled by default in 5.3? yes > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default yes > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case yes > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things > are in HEAD and make it clear that they will be available for bug > fixing and BC issues resolving. the risk here is obviously that any BC > issues will be hard to isolate for end users. abstention > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 abstention cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] quick polls for 5.3
Hi! 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default II) remove ext/mhash I) +1 II) Can't we make mhash "stub" extension with dependency on hash so only thing you get when you load it is that extension_loaded is OK and no BC break? Dependency would ensure the functions are there, and we get the bets of both worlds. 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 -0.5 I'd say not yet, but don't care too much. 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case 0 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -1 for now Need more explanation why we need rewrite, what the rewrite does, etc. If there's a good reason and maintainer, then maybe +1. 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 Same as above. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On 12-Nov-08, at 2:14 PM, Lukas Kahwe Smith wrote: Hi, here are a few questions that need to be answered ASAP. If at all possible keep your votes as short as possible. I think all of the above topics have been discussed quite a lot on the list. So I hope voters can spare the list needless repetition. Instead if you think that a topic needs to be discussed, put a short note in your vote under the given topic. If a number of people also think the topic needs more discussion, then we can open a new thread dedicated to this topic later this week. 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default II) remove ext/mhash +1 (for both) 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) b) Should we instead just throw an E_STRICT c) Document as is (c) +1 4) keep ext/phar enabled by default in 5.3? -0 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1 for all 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -1 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 +1 (b) Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On 12 Nov 2008, at 14:14, Lukas Kahwe Smith wrote: Hi, here are a few questions that need to be answered ASAP. If at all possible keep your votes as short as possible. I think all of the above topics have been discussed quite a lot on the list. So I hope voters can spare the list needless repetition. Instead if you think that a topic needs to be discussed, put a short note in your vote under the given topic. If a number of people also think the topic needs more discussion, then we can open a new thread dedicated to this topic later this week. 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default +1 II) remove ext/mhash +1 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) +1 b) Should we instead just throw an E_STRICT c) Document as is 4) keep ext/phar enabled by default in 5.3? +0 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default +1 II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1, i'd like to see ext/mysql removed 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -0 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 +1 Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi Lukas, 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default +1 II) remove ext/mhash -1, BC concerns. Can't we just deprecate it in 5.3 and remove in 6.0? 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) b) Should we instead just throw an E_STRICT c) Document as is C 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default +1 II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1... if it was just one extension OK, but three is too many 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. +0.5.. I'd really like to see it in 5.3 because it was supposed to fix several OB issues, but it's probably too late in the cycle now 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 0 (not enough insight to vote on this) Thanks, - Steph regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- 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] quick polls for 5.3
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash +0 > > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +0 > > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is b > > 4) keep ext/phar enabled by default in 5.3? +1 > > 5) keep ext/sqlite3 enabled by default in 5.3? +0 > > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case +1 on both > > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +1 > > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 +0 -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default II) remove ext/mhash +1 both 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) c) Document as is c 4) keep ext/phar enabled by default in 5.3? -0 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1 both 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -1 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) b) MFH to 5.3 b Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
hi Lukas! Thanks for this nice little list, 1st class troll killer :) On Wed, Nov 12, 2008 at 8:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > c) Document as is +1 > 4) keep ext/phar enabled by default in 5.3? 0 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case +1 > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +1 (if it creates non fixable issues during the alpha/RC phases, it can always be reverted. However the code is much cleaner and easier to maintain, if I can use the word "easy" for the OB code) > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > b) MFH to 5.3 +1 (there is tests, there is people taking of it if there are issues, more tests can be added as wish, it removes duplicate codes) 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] quick polls for 5.3
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > c) Document as is +1 > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default I'd say personally +1 because I have it enabled everywhere already but thinking in a larger user base where not everyone is using mysql I have to say -1 > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case +1 if it ends up turned on by default, -1 otherwise. > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. -1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > b) MFH to 5.3 +1 -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wednesday 12 November 2008 20:14:31 Lukas Kahwe Smith wrote: > Hi, > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > break will be that "if (extension_loaded('mhash'))" will need fixing > if mhash is removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash -0 > > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ > ereg is more or less redundant with ext/preg and is likely to not get > much unicode love for PHP 6, the question is if we should mark it with > a E_DEPRECATED in PHP 5.3 +1 (and allow the --without-ereg switch) > > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate > STDIN and friends) > b) Should we instead just throw an E_STRICT > c) Document as is a > > 4) keep ext/phar enabled by default in 5.3? +1 > > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default -0 > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case > > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things > are in HEAD and make it clear that they will be available for bug > fixing and BC issues resolving. the risk here is obviously that any BC > issues will be hard to isolate for end users. +0 Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wednesday 12 November 2008 1:14:31 pm Lukas Kahwe Smith wrote: > Hi, > > here are a few questions that need to be answered ASAP. > > If at all possible keep your votes as short as possible. I think all > of the above topics have been discussed quite a lot on the list. So I > hope voters can spare the list needless repetition. Instead if you > think that a topic needs to be discussed, put a short note in your > vote under the given topic. If a number of people also think the topic > needs more discussion, then we can open a new thread dedicated to this > topic later this week. > > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > break will be that "if (extension_loaded('mhash'))" will need fixing > if mhash is removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash -1, better to E_DEPRECATE for a version first then remove. > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ > ereg is more or less redundant with ext/preg and is likely to not get > much unicode love for PHP 6, the question is if we should mark it with > a E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate > STDIN and friends) > b) Should we instead just throw an E_STRICT > c) Document as is +0 > 4) keep ext/phar enabled by default in 5.3? +0 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default +1 > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case +1 > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things > are in HEAD and make it clear that they will be available for bug > fixing and BC issues resolving. the risk here is obviously that any BC > issues will be hard to isolate for end users. +0 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 +0 -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Lukas Kahwe Smith wrote: 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default 0 II) remove ext/mhash 0 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) b) Should we instead just throw an E_STRICT c) Document as is c 4) keep ext/phar enabled by default in 5.3? -1 5) keep ext/sqlite3 enabled by default in 5.3? -1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default -1 II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1 Many people do not use MySQL so it should not be enabled by default. This is even more important if it gets compiled in by default in windows builds. 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. Am using output buffering but don't know what effect this has. 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 Don't know. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]>wrote: > Hi, > > here are a few questions that need to be answered ASAP. > > If at all possible keep your votes as short as possible. I think all of the > above topics have been discussed quite a lot on the list. So I hope voters > can spare the list needless repetition. Instead if you think that a topic > needs to be discussed, put a short note in your vote under the given topic. > If a number of people also think the topic needs more discussion, then we > can open a new thread dedicated to this topic later this week. > > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default > II) remove ext/mhash > 0 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is 0 > 4) keep ext/phar enabled by default in 5.3? 0 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case 0 > 7) should Output buffering rewrite MFH? this one comes with some baggage, > we need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. 0 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 0 regards, > Lukas Kahwe Smith > [EMAIL PROTECTED] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Best regards, Konstantin Leboev
Re: [PHP-DEV] quick polls for 5.3
Lukas Kahwe Smith wrote: 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default +1 II) remove ext/mhash +1 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 3) resource constants (choose one) a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) b) Should we instead just throw an E_STRICT c) Document as is c 4) keep ext/phar enabled by default in 5.3? -1 5) keep ext/sqlite3 enabled by default in 5.3? +1 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default +1 II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case +1 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. +1 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so either (choose one) a) revert in HEAD b) MFH to 5.3 a -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] quick polls for 5.3
On Wed Nov 12 02:14 PM, Lukas Kahwe Smith wrote: > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > I) enable ext/hash by default +1 > II) remove ext/mhash 0 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ +1 > 3) resource constants (choose one) c > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? 0 > 6) enable mysqlnd by default in 5.3? (answer both) -1 both: would favor mysql by including client in default installation > 7) should Output buffering rewrite MFH? this one comes with some > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so 0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is "c" > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default +1 > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case -1 > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +0 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 "b" -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Thu, Nov 13, 2008 at 12:56 PM, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote: > On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > >> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break >> will be that "if (extension_loaded('mhash'))" will need fixing if mhash is >> removed (answer both) >> I) enable ext/hash by default +1 >> II) remove ext/mhash +1 >> 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg >> is more or less redundant with ext/preg and is likely to not get much >> unicode love for PHP 6, the question is if we should mark it with a >> E_DEPRECATED in PHP 5.3 +1 >> 3) resource constants (choose one) >> a) Should we deprecate constant resources (mostly used to emulate STDIN and >> friends) >> b) Should we instead just throw an E_STRICT >> c) Document as is > "c" C is ok > >> 4) keep ext/phar enabled by default in 5.3? Strongly +1 >> 5) keep ext/sqlite3 enabled by default in 5.3? 0 >> 6) enable mysqlnd by default in 5.3? (answer both) >> I) enable mysqlnd by default -1 >> II) also enable ext/mysql, mysqli und pdo_mysql by default since there will >> be no external dependencies in this case -1 >> 7) should Output buffering rewrite MFH? this one comes with some baggage, we >> need enough people to actually have a look at how things are in HEAD and >> make it clear that they will be available for bug fixing and BC issues >> resolving. the risk here is obviously that any BC issues will be hard to >> isolate for end users. +1 >> 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so >> either (choose one) >> a) revert in HEAD >> b) MFH to 5.3 0 > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > > -- > 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) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hello Lukas, Wednesday, November 12, 2008, 8:14:31 PM, you wrote: > Hi, > here are a few questions that need to be answered ASAP. > If at all possible keep your votes as short as possible. I think all > of the above topics have been discussed quite a lot on the list. So I > hope voters can spare the list needless repetition. Instead if you > think that a topic needs to be discussed, put a short note in your > vote under the given topic. If a number of people also think the topic > needs more discussion, then we can open a new thread dedicated to this > topic later this week. > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > break will be that "if (extension_loaded('mhash'))" will need fixing > if mhash is removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ > ereg is more or less redundant with ext/preg and is likely to not get > much unicode love for PHP 6, the question is if we should mark it with > a E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate > STDIN and friends) > b) Should we instead just throw an E_STRICT > c) Document as is "c" > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case +0 > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things > are in HEAD and make it clear that they will be available for bug > fixing and BC issues resolving. the risk here is obviously that any BC > issues will be hard to isolate for end users. +1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 +1 In short, MFH what we can, keep at least one DB in PHP per default. Enable all by default that does not depend on any library or move to PECL. Introduce stuff to core, enabled by default that we develop for mainstream usage. Do not do unneccessary changes, clarify docs always. And last but not least adhere to KISS and consistency. > regards, > Lukas Kahwe Smith > [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi, Thank you all for participating and raising any issues/concerns in a concise manner. I will tally up the votes sometime over the weekend and discuss the results with Johannes. We will then post what decisions we will take based on the votes (though in some cases we might need to hold off a decision until we have discussed the change with the person that maintains the given code). So in the mean time for all who have not voted, please do so now. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] quick polls for 5.3
On Thu, 2008-11-13 at 09:40 -0500, Jonathan Bond-Caron wrote: > > 6) enable mysqlnd by default in 5.3? (answer both) > > -1 both: would favor mysql by including client in default installation For clarification: mysqlnd is a PHP-specific replacement for the MySQL Client Library (libmysql) so adding mysqlnd as default means "including client in default installation". By using mysqlnd there are no external dependencies left. johannes -- Johannes Schlüter - MySQL Engineering, Connectors and Client Connectivity Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht München: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Wed, Nov 12, 2008 at 9:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]>wrote: > Hi, > > here are a few questions that need to be answered ASAP. > > If at all possible keep your votes as short as possible. I think all of the > above topics have been discussed quite a lot on the list. So I hope voters > can spare the list needless repetition. Instead if you think that a topic > needs to be discussed, put a short note in your vote under the given topic. > If a number of people also think the topic needs more discussion, then we > can open a new thread dedicated to this topic later this week. > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default > II) remove ext/mhash +1 +1 > > > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +1 > > > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is a > > > 4) keep ext/phar enabled by default in 5.3? +1 > > > 5) keep ext/sqlite3 enabled by default in 5.3? -1 > > > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case +1 +1 > > > 7) should Output buffering rewrite MFH? this one comes with some baggage, > we need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +0 > > > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 b > > > regards, > Lukas Kahwe Smith > [EMAIL PROTECTED] > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] quick polls for 5.3
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break > will be that "if (extension_loaded('mhash'))" will need fixing if mhash is > removed (answer both) > I) enable ext/hash by default +0 > II) remove ext/mhash +1 > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg > is more or less redundant with ext/preg and is likely to not get much > unicode love for PHP 6, the question is if we should mark it with a > E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is C > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default > II) also enable ext/mysql, mysqli und pdo_mysql by default since there will > be no external dependencies in this case +1 > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 +0 -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On Thu, Nov 13, 2008 at 4:14 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > 1) ext/mhash in 5.3. > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN and > friends) > b) Should we instead just throw an E_STRICT > c) Document as is a > 4) keep ext/phar enabled by default in 5.3? +1 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default -1 > II) also enable ext/mysql, mysqli and pdo_mysql by default since there will > be no external dependencies in this case -1 > 7) should Output buffering rewrite MFH? this one comes with some baggage, we > need enough people to actually have a look at how things are in HEAD and > make it clear that they will be available for bug fixing and BC issues > resolving. the risk here is obviously that any BC issues will be hard to > isolate for end users. +1 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 b -- moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hello All, First up thanks for this every efficient thread! Really makes the life for Johannes and myself a lot easier when we can so easily get an overview of the opinions on internals. After having discussed the results, we want to publish our conclusions .. 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default +1 Lukas +1 David C. +1 Hannes +1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Stas +1 Ilia +1 Steph +1 Scott +1 Kalle +1 David S.P. +1 Rob +1 Pierre +1 Arnaud Le Blanc +1 Larry Garfield +0 Lester Caine +0 Konstantin Leboev +1 Jani +1 Jonathan Bond-Caron +1 George Antoniadis +0 Felipe +1 Moriyoshi => keep ext/hash enabled by default II) remove ext/mhash +1 Lukas +1 David +1 Hannes +1 Matt Wilson +0 Greg +1 Derick +1 Elizabeth +1 Lars (Probably hack ZEND_FUNCTION(extension_loaded) to return true when "mhash" is passed and throw a deprecation warning. Is pretty easy but ugly. What would our ZE guys suggest to accomplish something like that?) +1 Stas (Can't we make mhash "stub" extension with dependency on hash so only thing you get when you load it is that extension_loaded is OK and no BC break? Dependency would ensure the functions are there, and we get the bets of both worlds.) +1 Ilia -1 Steph BC concerns. Can't we just deprecate it in 5.3 and remove in 6.0? +1 Scott +0 Kalle +1 David S.P. +1 Rob +1 Pierre +0 Arnaud Le Blanc -1 Larry Garfield better to E_DEPRECATE for a version first then remove. +0 Lester Caine +0 Konstantin Leboev +1 Jani +0 Jonathan Bond-Caron +1 George Antoniadis +1 Felipe +1 Moriyoshi => remove ext/mhash (someone may propose some stub/magic solution for extension_loaded('mhash')) 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 Lukas +1 David +1 Hannes +1 Matt Wilson +1 Greg -1 Derick +1 Elizabeth +1 Lars -0.5 Stas I'd say not yet, but don't care too much. +1 Ilia +1 Steph +1 Scott +0 Kalle +1 David S.P. +1 Rob +1 Pierre +1 Arnaud Le Blanc (and allow the --without-ereg switch) +1 Larry Garfield +1 Lester Caine +1 Konstantin Leboev +1 Jani +1 Jonathan Bond-Caron +1 George Antoniadis +1 Felipe +1 Moriyoshi => deprecate ext/ereg and remove in PHP 6 3) resource constants (choose one) +0 Stas +0 Larry Garfield +0 Konstantin Leboev a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) +1 Scott +1 Arnaud Le Blanc +1 George Antoniadis +1 Moriyoshi b) Should we instead just throw an E_STRICT +1 Kalle c) Document as is +1 Lukas +1 David +1 Hannes +1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Ilia +1 Steph +1 David S.P. +1 Rob +1 Pierre +1 Lester Caine +1 Jani +1 Jonathan Bond-Caron +1 Felipe => document as is 4) keep ext/phar enabled by default in 5.3? +1 Lukas +1 David -1 Hannes -1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Stas +0 Ilia +1 Steph +0 Scott +1 Kalle +1 David S.P. +0 Rob +0 Pierre +1 Arnaud Le Blanc +0 Larry Garfield -1 Lester Caine +0 Konstantin Leboev -1 Jani +1 Jonathan Bond-Caron +1 George Antoniadis +1 Felipe +1 Moriyoshi => keep ext/phar enabled 5) keep ext/sqlite3 enabled by default in 5.3? +1 Lukas +1 David +0 Hannes -1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Stas +1 Ilia +1 Steph +1 Scott +0 Kalle +1 David S.P. +1 Rob +1 Pierre +1 Arnaud Le Blanc +1 Larry Garfield -1 Lester Caine +1 Konstantin Leboev +1 Jani +0 Jonathan Bond-Caron -1 George Antoniadis +1 Felipe +1 Moriyoshi => keep ext/sqlite3 enabled 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default -1 Lukas -1 David -0 Hannes -1 Matt Wilson +0 Greg -1 Derick +0 Elizabeth +1 Lars +0 Stas -1 Ilia +1 Steph +1 Scott +1 Kalle +0 David S.P. -1 Rob +1 Pierre +0 Arnaud Le Blanc +1 Larry Garfield -1 Lester Caine Many people do not use MySQL so it should not be enabled by default. This is even more important if it gets compiled in by default in windows builds. +0 Konstantin Leboev +1 Jani -1 Jonathan Bond-Caron would favor mysql by including client in default installation (Clarification by Johannes: mysqlnd is a PHP- specific replacement for the MySQL Client Library (libmysql) so adding mysqlnd as default means "including client in default installation". By using mysqlnd there are no external dependencies left.) +1 George Antoniadis +1 Felipe -1 Moriyoshi => do not enable by default since there is not enough support to add something (assumption when in doubt do not add) II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be no external dependencies in this case -1 Lukas +1 David -0 Hannes -1 Matt Wilson +0 Greg -1 Derick +0 Elizabeth +1 Lars +0 Stas -1 Ilia -1 Steph if it w
Re: [PHP-DEV] quick polls for 5.3 (sorry missed a couple votes, but they did not affect the results)
Hello All, First up thanks for this every efficient thread! Really makes the life for Johannes and myself a lot easier when we can so easily get an overview of the opinions on internals. After having discussed the results, we want to publish our conclusions .. 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break will be that "if (extension_loaded('mhash'))" will need fixing if mhash is removed (answer both) I) enable ext/hash by default +1 Lukas +1 David C. +1 Hannes +1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Stas +1 Ilia +1 Steph +1 Scott +1 Kalle +1 David S.P. +1 Rob +1 Pierre +1 Arnaud Le Blanc +1 Larry Garfield +0 Lester Caine +0 Konstantin Leboev +1 Jani +1 Jonathan Bond-Caron +1 George Antoniadis +0 Felipe +1 Moriyoshi +1 Karsten Dambekalns +1 Alexey Zakhlestin +1 Marcus +1 Guilherme Blanco => keep ext/hash enabled by default II) remove ext/mhash +1 Lukas +1 David +1 Hannes +1 Matt Wilson +0 Greg +1 Derick +1 Elizabeth +1 Lars (Probably hack ZEND_FUNCTION(extension_loaded) to return true when "mhash" is passed and throw a deprecation warning. Is pretty easy but ugly. What would our ZE guys suggest to accomplish something like that?) +1 Stas (Can't we make mhash "stub" extension with dependency on hash so only thing you get when you load it is that extension_loaded is OK and no BC break? Dependency would ensure the functions are there, and we get the bets of both worlds.) +1 Ilia -1 Steph BC concerns. Can't we just deprecate it in 5.3 and remove in 6.0? +1 Scott +0 Kalle +1 David S.P. +1 Rob +1 Pierre +0 Arnaud Le Blanc -1 Larry Garfield better to E_DEPRECATE for a version first then remove. +0 Lester Caine +0 Konstantin Leboev +1 Jani +0 Jonathan Bond-Caron +1 George Antoniadis +1 Felipe +1 Moriyoshi +1 Karsten Dambekalns +1 Alexey Zakhlestin +1 Marcus +1 Guilherme Blanco => remove ext/mhash (someone may propose some stub/magic solution for extension_loaded('mhash')) 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ ereg is more or less redundant with ext/preg and is likely to not get much unicode love for PHP 6, the question is if we should mark it with a E_DEPRECATED in PHP 5.3 +1 Lukas +1 David +1 Hannes +1 Matt Wilson +1 Greg -1 Derick +1 Elizabeth +1 Lars -0.5 Stas I'd say not yet, but don't care too much. +1 Ilia +1 Steph +1 Scott +0 Kalle +1 David S.P. +1 Rob +1 Pierre +1 Arnaud Le Blanc (and allow the --without-ereg switch) +1 Larry Garfield +1 Lester Caine +1 Konstantin Leboev +1 Jani +1 Jonathan Bond-Caron +1 George Antoniadis +1 Felipe +1 Moriyoshi +1 Karsten Dambekalns +1 Alexey Zakhlestin +1 Marcus +1 Guilherme Blanco => deprecate ext/ereg and remove in PHP 6 3) resource constants (choose one) +0 Stas +0 Larry Garfield +0 Konstantin Leboev a) Should we deprecate constant resources (mostly used to emulate STDIN and friends) +1 Scott +1 Arnaud Le Blanc +1 George Antoniadis +1 Moriyoshi b) Should we instead just throw an E_STRICT +1 Kalle c) Document as is +1 Lukas +1 David +1 Hannes +1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Ilia +1 Steph +1 David S.P. +1 Rob +1 Pierre +1 Lester Caine +1 Jani +1 Jonathan Bond-Caron +1 Felipe +1 Karsten Dambekalns +1 Alexey Zakhlestin +1 Marcus +1 Guilherme Blanco => document as is 4) keep ext/phar enabled by default in 5.3? +1 Lukas +1 David -1 Hannes -1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Stas +0 Ilia +1 Steph +0 Scott +1 Kalle +1 David S.P. +0 Rob +0 Pierre +1 Arnaud Le Blanc +0 Larry Garfield -1 Lester Caine +0 Konstantin Leboev -1 Jani +1 Jonathan Bond-Caron +1 George Antoniadis +1 Felipe +1 Moriyoshi +1 Karsten Dambekalns +1 Alexey Zakhlestin +1 Marcus +1 Guilherme Blanco => keep ext/phar enabled 5) keep ext/sqlite3 enabled by default in 5.3? +1 Lukas +1 David +0 Hannes -1 Matt Wilson +1 Greg +1 Derick +1 Elizabeth +1 Lars +1 Stas +1 Ilia +1 Steph +1 Scott +0 Kalle +1 David S.P. +1 Rob +1 Pierre +1 Arnaud Le Blanc +1 Larry Garfield -1 Lester Caine +1 Konstantin Leboev +1 Jani +0 Jonathan Bond-Caron -1 George Antoniadis +1 Felipe +1 Moriyoshi +1 Karsten Dambekalns +1 Alexey Zakhlestin +0 Guilherme Blanco +1 Marcus => keep ext/sqlite3 enabled 6) enable mysqlnd by default in 5.3? (answer both) I) enable mysqlnd by default -1 Lukas -1 David -0 Hannes -1 Matt Wilson +0 Greg -1 Derick +0 Elizabeth +1 Lars +0 Stas -1 Ilia +1 Steph +1 Scott +1 Kalle +0 David S.P. -1 Rob +1 Pierre +0 Arnaud Le Blanc +1 Larry Garfield -1 Lester Caine Many people do not use MySQL so it should not be enabled by default. This is even more important if it gets compiled in by default in windows builds. +0 Konstantin Leboev +1 Jani -1 Jonathan Bond-Caron would favor mysql by including client in default installation (Clarification by Johannes: mysqlnd is a PHP- specific replacement for the MySQL Client Library (libmysql) so adding mysqlnd as default means "including client in default installation". By using mysqlnd there
Re: [PHP-DEV] quick polls for 5.3 (sorry missed a couple votes, but they did not affect the results)
Lukas Kahwe Smith wrote: > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things are > in HEAD and make it clear that they will be available for bug fixing and > BC issues resolving. the risk here is obviously that any BC issues will > be hard to isolate for end users. > > -1 Lukas > -1 David > +1 Hannes > +0 Matt Wilson > +0 Greg > +0 Derick > +1 Elizabeth > +0 Lars > -1 Stas for now Need more explanation why we need rewrite, what the > rewrite does, etc. If there's a good reason and maintainer, then maybe +1. > -1 Ilia > +0.5 Steph I'd really like to see it in 5.3 because it was supposed to > fix several OB issues, but it's probably too late in the cycle now > +0 Scott > +1 Kalle > -1 David S.P. for now Need more explanation why we need rewrite, what > the rewrite does, etc. If there's a good reason and maintainer, then > maybe +1. > -1 Rob > +1 Pierre (if it creates non fixable issues during the alpha/RC phases, > it can always be reverted. However the code is much cleaner and easier > to maintain, if I can use the word "easy" for the OB code) > +0 Arnaud Le Blanc > +0 Larry Garfield > +0 Lester Caine > +0 Konstantin Leboev > +1 Jani > +0 Jonathan Bond-Caron > +0 George Antoniadis > +1 Felipe > +1 Moriyoshi > +0 Karsten Dambekalns > +0 Alexey Zakhlestin > +1 Guilherme Blanco > +1 Marcus > > => no MFH, very unclear vote result and nobody that raised their hand to > take responsibility (yes Pierre I know that you raised your hand on IRC) Hm... I'm still alive, but I feel blamed for not reading a mailing list which has become unmanageable to read. I wrote the code, so I'm probably "responsible" for it, too. And again, I was asked several times to back port it, so it can be included in 5.3--which doesn't mean I'm insisting on that matter, just to make it clear. I've still got some email addresses which--despite of spam--I am able to read and respond in a reasonable time span. Usually you can even hit me on IRC. Feel free to ask me any questions per mail or on IRC, but don't expect me to read a quadrillion of mails on [EMAIL PROTECTED] Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php