# [VOTE] Remove deprecated functionality in PHP 7 - Thread: https://externals.io/message/80100 - Original archive: https://news-web.php.net/php.internals/80100 - Started by Nikita Popov on 2015-01-02T16:04:08+00:00 - Messages: 20 - RFC: Remove deprecated functionality in PHP 7 (Implemented (PHP 7.0)) — https://externals.io/rfc/remove_deprecated_functionality_in_php7.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #80100 — Nikita Popov — 2015-01-02T16:04:08+00:00 URL: https://externals.io/message/80100#80100 Hi internals! Voting on the removal of deprecated functionality in PHP 7 is now open: https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes As requested, I've split this up in many individual votes, only some particularly trivial function deprecations are left as a group. If you vote against the removal of an item, I would appreciate a mail with your reasons behind the choice and maybe suggestions as to what we should do with the item instead (leave deprecated / undeprecate it / provide missing alternatives / ...). Nikita --- ## #80108 — Pierre Joye — 2015-01-02T21:07:58+00:00 URL: https://externals.io/message/80100#80108 · In reply to: #80100 hi, > Hi internals! > > Voting on the removal of deprecated functionality in PHP 7 is now open: > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes > > As requested, I've split this up in many individual votes, only some > particularly trivial function deprecations are left as a group. > > If you vote against the removal of an item, I would appreciate a mail with > your reasons behind the choice and maybe suggestions as to what we should > do with the item instead (leave deprecated / undeprecate it / provide > missing alternatives / ...). It is incomplete. imap, mcrypt and a couple of dead SAPIs should be removed altogether, as they are both unmaitained. I know it is a different story but we should just have one RFC about what we want to remove instea of multiple similar RFCs (or even worst, one cancel part of another). -- Pierre @pierrejoye | http://www.libgd.org --- ## #80469 — Nikita Popov — 2015-01-14T15:40:09+00:00 URL: https://externals.io/message/80100#80469 · In reply to: #80100 > Hi internals! > > Voting on the removal of deprecated functionality in PHP 7 is now open: > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes > > As requested, I've split this up in many individual votes, only some > particularly trivial function deprecations are left as a group. > > If you vote against the removal of an item, I would appreciate a mail with > your reasons behind the choice and maybe suggestions as to what we should > do with the item instead (leave deprecated / undeprecate it / provide > missing alternatives / ...). > > Nikita > Reminder: This vote is closing in two days. Nikita --- ## #80506 — Pierre Joye — 2015-01-14T23:51:05+00:00 URL: https://externals.io/message/80100#80506 · In reply to: #80469 > > > > […] > > Reminder: This vote is closing in two days. Bummer, we will do other RFCs for the other things to be removed. Thanks for your reply on the matter tho'. --- ## #80591 — Pascal Martin — 2015-01-15T20:51:05+00:00 URL: https://externals.io/message/80100#80591 · In reply to: #80100 > Voting on the removal of deprecated functionality in PHP 7 is now open: > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes > > As requested, I've split this up in many individual votes, only some > particularly trivial function deprecations are left as a group. Hi, After some discussions with other people of AFUP, we ended up with a +1 on all points : a new major version is the right time to remove those deprecated features (else, they'll pretty much remain in PHP forever). -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ --- ## #80654 — Nikita Popov — 2015-01-16T17:16:58+00:00 URL: https://externals.io/message/80100#80654 · In reply to: #80100 > Hi internals! > > Voting on the removal of deprecated functionality in PHP 7 is now open: > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes > > As requested, I've split this up in many individual votes, only some > particularly trivial function deprecations are left as a group. > > If you vote against the removal of an item, I would appreciate a mail with > your reasons behind the choice and maybe suggestions as to what we should > do with the item instead (leave deprecated / undeprecate it / provide > missing alternatives / ...). > > Nikita > All items of this RFC have been accepted for removal in PHP 7. I'll land the minor removals sometime soon; the unbundling of ext/ereg and ext/mysql should probably be done by someone else who's more into the PECL business. Nikita --- ## #80718 — Yasuo Ohgaki — 2015-01-18T02:08:23+00:00 URL: https://externals.io/message/80100#80718 · In reply to: #80654 Hi Nikita, > All items of this RFC have been accepted for removal in PHP 7. > > I'll land the minor removals sometime soon; the unbundling of ext/ereg and > ext/mysql should probably be done by someone else who's more into the PECL > business. > iconv.input_encoding, iconv.output_encoding, iconv.internal_encoding, mbstring.http_input, mbstring.http_output and mbstring.internal_encoding (since PHP 5.6; use php.input_encoding, php.internal_encoding and php.output_encoding instead) [TODO] I may handle this if you would like. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #80733 — Nikita Popov — 2015-01-18T11:01:43+00:00 URL: https://externals.io/message/80100#80733 · In reply to: #80718 > Hi Nikita, > > On Sat, Jan 17, 2015 at 2:16 AM, Nikita Popov > wrote: > > > […] > > iconv.input_encoding, iconv.output_encoding, iconv.internal_encoding, > mbstring.http_input, mbstring.http_output and mbstring.internal_encoding > (since PHP 5.6; use php.input_encoding, php.internal_encoding and > php.output_encoding instead) [TODO] > > I may handle this if you would like. > That would be appreciated! When dropping the ini settings, please make sure that it's still possible to use Zend multibyte. If I remember correctly, right now Zend multibyte can only be used with the deprecated mbstring.internal_encoding setting, but not using php.internal_encoding. Thanks, Nikita --- ## #80762 — Yasuo Ohgaki — 2015-01-19T03:00:17+00:00 URL: https://externals.io/message/80100#80762 · In reply to: #80733 Hi Nikita, > That would be appreciated! When dropping the ini settings, please make > sure that it's still possible to use Zend multibyte. If I remember > correctly, right now Zend multibyte can only be used with the deprecated > mbstring.internal_encoding setting, but not using php.internal_encoding. Thank you for reminding! I'll get rid of old INIs after I finished session changes that is supposed to be included in PHP 5.6. Spending hours to get used to new PHP 7 APIs. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #80775 — Matteo Beccati — 2015-01-19T07:39:08+00:00 URL: https://externals.io/message/80100#80775 · In reply to: #80654 > Il giorno 16/gen/2015, alle ore 18:16, Nikita Popov ha scritto: > > I'll land the minor removals sometime soon; the unbundling of ext/ereg and > ext/mysql should probably be done by someone else who's more into the PECL > business. I can take care of the PDO::PGSQL constant, if you’d like. Cheers — Matteo --- ## #84311 — Adam Harvey — 2015-03-05T01:21:54+00:00 URL: https://externals.io/message/80100#84311 · In reply to: #80654 > I'll land the minor removals sometime soon; the unbundling of ext/ereg and > ext/mysql should probably be done by someone else who's more into the PECL > business. They gone. Many thanks to Tjerk, for doing all the hard work on the ereg front in PR form, and Hannes for setting up the new Git repositories in the PECL namespace for them to live in. Adam, who feels sorry for MySQL users, who now have a mere two APIs to choose from. --- ## #84340 — Jan Ehrhardt — 2015-03-05T13:39:19+00:00 URL: https://externals.io/message/80100#84340 · In reply to: #84311 Adam Harvey in php.internals (Wed, 4 Mar 2015 17:21:54 -0800): > > > […] > >They gone. > >Many thanks to Tjerk, for doing all the hard work on the ereg front in >PR form, and Hannes for setting up the new Git repositories in the >PECL namespace for them to live in. > >Adam, who feels sorry for MySQL users, who now have a mere two APIs to >choose from. I had already built a php_ereg.dll and a php_mysql.dll for PHP7, using the sources of two days ago. The config.w32 for ereg needs some changes, if you want to enable shared builds on Windows: http://git.php.net/?p=pecl/text/ereg.git;a=blob;f=config.w32 -ARG_WITH("ereg", "POSIX extended regular expressions", "yes"); +ARG_WITH("ereg", "POSIX extended regular expressions", "no"); - EXTENSION("ereg", "ereg.c", PHP_EREG_SHARED, "-Dregexec=php_regexec -Dregerror=php_regerror -Dregfree=php_regfree -Dregcomp=php_regcomp -Iext/ereg/regex /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1"); + EXTENSION("ereg", "ereg.c", PHP_EREG_SHARED, "-Dregexec=php_regexec -Dregerror=php_regerror -Dregfree=php_regfree -Dregcomp=php_regcomp -Iext/ereg/regex"); Jan --- ## #84348 — Adam Harvey — 2015-03-05T17:56:31+00:00 URL: https://externals.io/message/80100#84348 · In reply to: #84340 > I had already built a php_ereg.dll and a php_mysql.dll for PHP7, using > the sources of two days ago. The config.w32 for ereg needs some changes, > if you want to enable shared builds on Windows: > > http://git.php.net/?p=pecl/text/ereg.git;a=blob;f=config.w32 > > -ARG_WITH("ereg", "POSIX extended regular expressions", "yes"); > +ARG_WITH("ereg", "POSIX extended regular expressions", "no"); > > - EXTENSION("ereg", "ereg.c", PHP_EREG_SHARED, "-Dregexec=php_regexec -Dregerror=php_regerror -Dregfree=php_regfree -Dregcomp=php_regcomp -Iext/ereg/regex /DZEND_ENABLE_STATIC_TSRMLS_CACHE=1"); > + EXTENSION("ereg", "ereg.c", PHP_EREG_SHARED, "-Dregexec=php_regexec -Dregerror=php_regerror -Dregfree=php_regfree -Dregcomp=php_regcomp -Iext/ereg/regex"); Thanks; applied. I meant to ask someone to check the config.w32 files, and was too braindead due to work and this by the time I sent the e-mail to remember. Adam --- ## #84351 — Pierre Joye — 2015-03-05T20:21:01+00:00 URL: https://externals.io/message/80100#84351 · In reply to: #84348 > > > […] > > Thanks; applied. I meant to ask someone to check the config.w32 files, > and was too braindead due to work and this by the time I sent the > e-mail to remember. Thanks for making the move! It would be good to do a pecl release for each of them, and mark the package as deprecated/overseeded by mysqli (I let you choose). Doing so will trigger a build there, cleaner. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #84353 — Adam Harvey — 2015-03-05T20:29:35+00:00 URL: https://externals.io/message/80100#84353 · In reply to: #84351 > It would be good to do a pecl release for each of them, and mark the > package as deprecated/overseeded by mysqli (I let you choose). Doing > so will trigger a build there, cleaner. I'm on the fence about making a release for ereg and mysql: it would help in terms of code availability, but at the same time I feel like it undermines our message of "no, really, don't use these at all in PHP 7", even though they'd be marked as unmaintained and deprecated. I guess I'm open to persuasion either way here. Adam --- ## #84354 — Pierre Joye — 2015-03-05T20:36:32+00:00 URL: https://externals.io/message/80100#84354 · In reply to: #84353 > > > […] > > I'm on the fence about making a release for ereg and mysql: it would > help in terms of code availability, but at the same time I feel like > it undermines our message of "no, really, don't use these at all in > PHP 7", even though they'd be marked as unmaintained and deprecated. > > I guess I'm open to persuasion either way here. Same here. First time we moved ext to pecl I was saying that we should not provide any release and not even use pecl for that. We disagreed, so I think we should be consistent here and move on. While I do think that a lot of bad things may happen with people starting to install ext/mysql from pecl =) -- Pierre @pierrejoye | http://www.libgd.org --- ## #85947 — Nikita Popov — 2015-04-24T16:44:47+00:00 URL: https://externals.io/message/80100#85947 · In reply to: #80762 > Hi Nikita, > > On Sun, Jan 18, 2015 at 8:01 PM, Nikita Popov > wrote: > > > […] > > > Thank you for reminding! > I'll get rid of old INIs after I finished session changes that is supposed > to be included in PHP 5.6. > Spending hours to get used to new PHP 7 APIs. > All items mentioned in the RFC are removed now, excepting the mbstring/iconv encoding settings. I tried doing that, but it looks like the new encoding settings don't actually work. I also noticed that they were introduced under the names XYZ_encoding instead of php.XYZ_encoding, as the RFC says. Nikita --- ## #85948 — Yasuo Ohgaki — 2015-04-24T20:11:12+00:00 URL: https://externals.io/message/80100#85948 · In reply to: #85947 Hi Nikita, > All items mentioned in the RFC are removed now, excepting the > mbstring/iconv encoding settings. I tried doing that, but it looks like the > new encoding settings don't actually work. I also noticed that they were > introduced under the names XYZ_encoding instead of php.XYZ_encoding, as the > RFC says. I'm not sure what do you mean by "I also noticed that they were introduced under the names XYZ_encoding instead of php.XYZ_encoding, as the RFC says." because I cannot take a look at code now. Anyway, I have work in progress patch for it. However, I noticed that I need additional functions for iconv. http://php.net/manual/en/book.iconv.php iconv does not have functions set input/output/internal encoding for temporary purpose. e.g. To process external inputs that have encoding other than global setting. My work is stopped by this. Proper resolution for this would be introducing functions that set input/output/internal encoding for iconv. If nobody objects, I'll add these and finish my patch. Any comments? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #85949 — Nikita Popov — 2015-04-24T20:22:53+00:00 URL: https://externals.io/message/80100#85949 · In reply to: #85948 > Hi Nikita, > > On Sat, Apr 25, 2015 at 1:44 AM, Nikita Popov > wrote: > > > […] > > > I'm not sure what do you mean by "I also noticed that they were > introduced under the names XYZ_encoding instead of php.XYZ_encoding, as the > RFC says." because > I cannot take a look at code now. > > Anyway, I have work in progress patch for it. However, I noticed that I > need > additional functions for iconv. > > http://php.net/manual/en/book.iconv.php > > iconv does not have functions set input/output/internal encoding for > temporary > purpose. e.g. To process external inputs that have encoding other than > global > setting. My work is stopped by this. > > Proper resolution for this would be introducing functions that set > input/output/internal > encoding for iconv. > > If nobody objects, I'll add these and finish my patch. > Maybe we should just keep the mbstring and iconv ini settings (and undeprecate them)? If we retain the ability to set a per-extension encoding, we may just as well allow setting it via ini setting instead of extra functions. I think dropping these only makes sense if we drop the ability to have mbstring-specific or iconv-specific encoding settings altogether. Nikita --- ## #85950 — Yasuo Ohgaki — 2015-04-24T20:56:00+00:00 URL: https://externals.io/message/80100#85950 · In reply to: #85949 Hi Nikita, > Maybe we should just keep the mbstring and iconv ini settings (and > undeprecate them)? If we retain the ability to set a per-extension > encoding, we may just as well allow setting it via ini setting instead of > extra functions. I think dropping these only makes sense if we drop the > ability to have mbstring-specific or iconv-specific encoding settings > altogether. I agree. This will work, too. I don't mind keeping them at all. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net