[VOTE] Remove deprecated functionality in PHP 7

Pierre Joye

11 years ago

hi,

On Fri, Jan 2, 2015 at 8:04 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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

Nikita Popov

11 years ago

On Fri, Jan 2, 2015 at 5:04 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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

Pierre Joye

11 years ago

On Wed, Jan 14, 2015 at 4:40 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Fri, Jan 2, 2015 at 5:04 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> 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.

Bummer, we will do other RFCs for the other things to be removed.
Thanks for your reply on the matter tho'.

Pascal MARTIN

11 years ago

On 02/01/2015 17:04, Nikita Popov wrote:

> 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/

Nikita Popov

11 years ago

On Fri, Jan 2, 2015 at 5:04 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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

Yasuo Ohgaki

11 years ago

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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Nikita Popov

11 years ago

On Sun, Jan 18, 2015 at 3:08 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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

Yasuo Ohgaki

11 years ago

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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Nikita Popov

11 years ago

On Mon, Jan 19, 2015 at 4:00 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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

Yasuo Ohgaki

11 years ago

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.

Any comments?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Nikita Popov

11 years ago

On Fri, Apr 24, 2015 at 10:11 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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

Yasuo Ohgaki

11 years ago

Hi Nikita,

On Sat, Apr 25, 2015 at 5:22 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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

Matteo Beccati

11 years ago

> 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

Adam Harvey

11 years ago

On 16 January 2015 at 09:16, Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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.

Jan Ehrhardt

11 years ago

Adam Harvey in php.internals (Wed, 4 Mar 2015 17:21:54 -0800):

>On 16 January 2015 at 09:16, Nikita Popov <nikita.ppv@gmail.com> wrote:
>> 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

Adam Harvey

11 years ago

On 5 March 2015 at 05:39, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote:

> 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

Pierre Joye

11 years ago

On Thu, Mar 5, 2015 at 9:56 AM, Adam Harvey <aharvey@php.net> wrote:

> On 5 March 2015 at 05:39, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote:
>> 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

Adam Harvey

11 years ago

On 5 March 2015 at 12:21, Pierre Joye <pierre.php@gmail.com> wrote:

> 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

Pierre Joye

11 years ago

On Thu, Mar 5, 2015 at 12:29 PM, Adam Harvey <aharvey@php.net> wrote:

> On 5 March 2015 at 12:21, Pierre Joye <pierre.php@gmail.com> wrote:
>> 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

Jan Ehrhardt

11 years ago

Pierre Joye in php.internals (Thu, 5 Mar 2015 12:36:32 -0800):

>On Thu, Mar 5, 2015 at 12:29 PM, Adam Harvey <aharvey@php.net> wrote:
>> 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 =)

On the other hand: there is a chance they might switch to PHP7 earlier.
I have got some really old legacy code (dating back to 2005), which is
safely guarded against SQL injection and the like. I did a quick test
and only a few changes were needed to let it run on PHP7. This involved
changes like $$hash into ${$hash}. BTW: Piwik heavily uses $$ even in
the latest releases, so it is not as old-style-coding as you might
think.

We are gradually moving our legacy sites to Drupal 7/8, so we will not
spend time on moving the old code from MySQL to MySQLi. But PHP7 has a
lot of benefits as well. Be sure I will be installing MySQL as shared
extension for PHP7.

Jan

Lester Caine

11 years ago

On 05/03/15 21:19, Jan Ehrhardt wrote:

> BTW: Piwik heavily uses $$ even in
> the latest releases, so it is not as old-style-coding as you might
> think.

Thanks for that Jan ... my own port of piwik is on the todo list here!

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk