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
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#votesAs 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
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#votesAs 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
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#votesAs 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.
Bummer, we will do other RFCs for the other things to be removed.
Thanks for your reply on the matter tho'.
Voting on the removal of deprecated functionality in PHP 7 is now open:
https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votesAs 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/
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#votesAs 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
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
Hi Nikita,
On Sat, Jan 17, 2015 at 2:16 AM, Nikita Popov nikita.ppv@gmail.com
wrote: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.
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
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
Hi Nikita,
On Sun, Jan 18, 2015 at 8:01 PM, Nikita Popov nikita.ppv@gmail.com
wrote: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.
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
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
Hi Nikita,
On Sat, Apr 25, 2015 at 1:44 AM, Nikita Popov nikita.ppv@gmail.com
wrote: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.
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
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
Il giorno 16/gen/2015, alle ore 18:16, Nikita Popov nikita.ppv@gmail.com 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
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.
Adam Harvey in php.internals (Wed, 4 Mar 2015 17:21:54 -0800):
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.
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
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
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.
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
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
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.
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