# [RFC] Remove deprecated functionality in PHP 7

- Thread: https://externals.io/message/77882
- Original archive: https://news-web.php.net/php.internals/77882
- Started by Nikita Popov on 2014-10-11T20:52:21+00:00
- Messages: 47
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/77882.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #77882 — Nikita Popov — 2014-10-11T20:52:21+00:00

URL: https://externals.io/message/77882#77882

Hi internals!

We currently have a number of deprecated features, which we likely want to
remove in PHP 7. I've created a tracking RFC listing deprecated
functionality (if I missed something, please tell):

    https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7

I expect many of these are no-brainers (like assigning new by-reference),
but other items like removal of ext/mysql may need additional consideration.

Unless there are items that are particularly contested, I'd like to handle
the bulk of these in a single vote and only have separate votes for
ext/ereg and ext/mysql, as these are arguably more intrusive.

Thanks,
Nikita

---

## #77885 — Kris Craig — 2014-10-11T23:47:47+00:00

URL: https://externals.io/message/77882#77885 · In reply to: #77882

>
> Hi internals!
>
> We currently have a number of deprecated features, which we likely want to
> remove in PHP 7. I've created a tracking RFC listing deprecated
> functionality (if I missed something, please tell):
>
>     https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
>
> I expect many of these are no-brainers (like assigning new by-reference),
> but other items like removal of ext/mysql may need additional
consideration.
>
> Unless there are items that are particularly contested, I'd like to handle
> the bulk of these in a single vote and only have separate votes for
> ext/ereg and ext/mysql, as these are arguably more intrusive.
>
> Thanks,
> Nikita

+1 on all of that.

As far as ext/mysql is concerned, I would eagerly vote in favor of removing
it.  It performs poorly, is procedural, less secure, doesn't support
prepared statements, etc.

It's always annoyed me how sites like w3schools still teach people to use
ext/mysql.  It's been deprecated for quite awhile now and I think it's time
to pull the plug on it.

--Kris

---

## #77886 — Rasmus Lerdorf — 2014-10-12T00:13:20+00:00

URL: https://externals.io/message/77882#77886 · In reply to: #77885

> 
> 
> > […]
> consideration.
> > […]
> 
> +1 on all of that.
> 
> As far as ext/mysql is concerned, I would eagerly vote in favor of removing
> it.  It performs poorly, is procedural, less secure, doesn't support
> prepared statements, etc.
> 
> It's always annoyed me how sites like w3schools still teach people to use
> ext/mysql.  It's been deprecated for quite awhile now and I think it's time
> to pull the plug on it.

Keep in mind though that it would be mostly symbolic. The majority of users get their PHP and extensions from distros. And distros have been separating out core-bundled extensions for a decade now. Users have absolutely no idea whether their php-mysql package comes from core or from pecl, nor do they care. So, unbundling it on our side will have close to zero impact on its use. In fact, in a weird way it might actually help make people continue to use it because if we unbundle it and stick it in pecl we would obviously not have it spew out 'deprecated' notices like we do as of 5.5. I mean, we still could, of course, but it would be weird having a non-core pecl extension declare itself deprecated. 

I am not against unbundling it, I just don't think it will achieve what you hope it will.

-Rasmus

---

## #77892 — Derick Rethans — 2014-10-12T07:54:08+00:00

URL: https://externals.io/message/77882#77892 · In reply to: #77885

> 
> > […]
> 
> +1 on all of that.
> 
> As far as ext/mysql is concerned, I would eagerly vote in favor of removing
> it.  It performs poorly, is procedural, less secure, doesn't support

"is procedural" is however, never a reason to remove something. As most 
of PHP's function library, is procedural and works just fine.

Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #77893 — Derick Rethans — 2014-10-12T07:56:38+00:00

URL: https://externals.io/message/77882#77893 · In reply to: #77882

> Hi internals!
> 
> We currently have a number of deprecated features, which we likely want to
> remove in PHP 7. I've created a tracking RFC listing deprecated
> functionality (if I missed something, please tell):
> 
>     https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
> 
> I expect many of these are no-brainers (like assigning new 
> by-reference), but other items like removal of ext/mysql may need 
> additional consideration.
> 
> Unless there are items that are particularly contested, I'd like to handle
> the bulk of these in a single vote and only have separate votes for
> ext/ereg and ext/mysql, as these are arguably more intrusive.

I think there should be a little bit more voting "options" - or rather 
categories. 

For example, things like this:

 # style comments in ini files (since PHP 5.3)

I don't think we should remove at all (or why is this even deprecated?!

cheers,
Derick
-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #77894 — Lester Caine — 2014-10-12T07:59:38+00:00

URL: https://externals.io/message/77882#77894 · In reply to: #77886

> Keep in mind though that it would be mostly symbolic. The majority of users get their PHP and extensions from distros. And distros have been separating out core-bundled extensions for a decade now. Users have absolutely no idea whether their php-mysql package comes from core or from pecl, nor do they care. So, unbundling it on our side will have close to zero impact on its use. In fact, in a weird way it might actually help make people continue to use it because if we unbundle it and stick it in pecl we would obviously not have it spew out 'deprecated' notices like we do as of 5.5. I mean, we still could, of course, but it would be weird having a non-core pecl extension declare itself deprecated. 
> 
> I am not against unbundling it, I just don't think it will achieve what you hope it will.

I may be wrong but certainly SUSE bundles mysql, mysqli and pdo_mysql in
the one package and I think most do?

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

---

## #77895 — Kris Craig — 2014-10-12T08:19:05+00:00

URL: https://externals.io/message/77882#77895 · In reply to: #77892

>
> 
>
> > […]
removing
> > […]
>
> "is procedural" is however, never a reason to remove something. As most
> of PHP's function library, is procedural and works just fine.

Fair point.  I agree that alone wouldn't be grounds to remove it.  I was
just citing that as one of many deficiencies compared to more current
extensions like ext/mysqli.

--Kris

>
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine

---

## #77900 — Nikita Popov — 2014-10-12T10:11:03+00:00

URL: https://externals.io/message/77882#77900 · In reply to: #77893

> 
>
> > […]
> to
> > […]
> handle
> > […]
>
> I think there should be a little bit more voting "options" - or rather
> categories.
>
> For example, things like this:
>
>  # style comments in ini files (since PHP 5.3)
>
> I don't think we should remove at all (or why is this even deprecated?!
>

Because ini files use ; for comments and not #.

Nikita

---

## #77901 — Maciej Sobaczewski — 2014-10-12T10:23:41+00:00

URL: https://externals.io/message/77882#77901 · In reply to: #77900

> > […]
>
> Because ini files use ; for comments and not #.
>
> Nikita
>

And once again it's one of the simplest things to fix. Single 
find&replace should do the trick in most cases.

Thanks,
Maciej.

---

## #77902 — Zeev Suraski — 2014-10-12T10:36:25+00:00

URL: https://externals.io/message/77882#77902 · In reply to: #77900

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Sunday, October 12, 2014 1:11 PM
> To: Derick Rethans
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
>
> 
>
> > […]
>
> Because ini files use ; for comments and not #.

For the record, I don't feel strongly about # comments, but I do think that
we should have good reasons to actually *remove* features that are better
than "this is how it's done".  Valid reasons can be performance penalties of
keeping the feature, security issues, or potential significant reduction in
codebase complexity.  I'm not sure whether # comments fall into any of these
buckets, but sounds like they don't.

<broken_record>Each and every feature we break makes it a bit more difficult
to upgrade.  The more difficult we make it - the more people are likely to
stick with old insecure versions, or visit alternative
options</broken_record>

Zeev

---

## #77903 — Andrea Faulds — 2014-10-12T12:39:42+00:00

URL: https://externals.io/message/77882#77903 · In reply to: #77902

> For the record, I don't feel strongly about # comments, but I do think that
> we should have good reasons to actually *remove* features that are better
> than "this is how it's done".  Valid reasons can be performance penalties of
> keeping the feature, security issues, or potential significant reduction in
> codebase complexity.  I'm not sure whether # comments fall into any of these
> buckets, but sounds like they don’t.

Allowing # for comments stops you from using # in string property values.

Though I’m not sure why you’d need to.

--
Andrea Faulds
http://ajf.me/

---

## #77904 — Yannick Komotir — 2014-10-12T22:25:58+00:00

URL: https://externals.io/message/77882#77904 · In reply to: #77903

Hi Andrea,

> Allowing # for comments stops you from using # in string property values.
>
> Though I'm not sure why you'd need to.

That will be the case for any character to use for comments. Uses ;
for comments will stop you from using it in values.

Regards.

--
Yannick K.

---

## #77905 — Rowan Collins — 2014-10-13T00:35:09+00:00

URL: https://externals.io/message/77882#77905 · In reply to: #77900

> > […]
> Because ini files use ; for comments and not #.

I was curious enough about this to dig into source control and do some 
sleuthing, and it looks like what actually led to this situation was:

- Between 5.2 and 5.3 (late 2007 and early 2008), the ini parsing code 
saw a lot of heavy modifications [1], including a patch adding many new 
syntax features, and a subsequent rewrite from flex to re2c.
- This, inevitably, led to a bunch of regressions. As later pointed out, 
the accepted format wasn't really documented in the first place. [2]
- One of those bugs had to do with the parsing of # characters. [3]
- The behaviour of # as comments in earlier versions seems to have been 
a side-effect of something else, rather than a deliberate feature. In 
fact, it was possible to have a key starting with #, but a line starting 
# that had no = was silently discarded. [4]
- As a result, # was added back as an explicit comment character, but 
with a deprecation notice. [5]

My guess is that the reasoning was that semicolon was always the 
"correct" comment character, so people should be encouraged to use it.

Whether "deprecated" is the right word for that, I'm not sure.

[1] http://lxr.php.net/history/PHP_5_3/Zend/zend_ini_scanner.l
[2] https://bugs.php.net/bug.php?id=47703
[3] https://bugs.php.net/bug.php?id=44575
[4] http://3v4l.org/AoI5H
[5] 
http://lxr.php.net/diff/PHP_5_3/Zend/zend_ini_scanner.l?r2=%2FPHP_5_3%2FZend%2Fzend_ini_scanner.l%40b3d0514b6f87af37a7750a0f4c95e4a12a8f7009&r1=%2FPHP_5_3%2FZend%2Fzend_ini_scanner.l%40193dd31a22a52cfdbd30135b1025ca774d1e98b4

-- 
Rowan Collins
[IMSoP]

---

## #77908 — Pierre Joye — 2014-10-13T06:51:48+00:00

URL: https://externals.io/message/77882#77908 · In reply to: #77902

>
> For the record, I don't feel strongly about # comments, but I do think that
> we should have good reasons to actually *remove* features that are better
> than "this is how it's done".  Valid reasons can be performance penalties of
> keeping the feature, security issues, or potential significant reduction in
> codebase complexity.  I'm not sure whether # comments fall into any of these
> buckets, but sounds like they don't.
>
> <broken_record>Each and every feature we break makes it a bit more difficult
> to upgrade.  The more difficult we make it - the more people are likely to
> stick with old insecure versions, or visit alternative
> options</broken_record>

I have to agree with Zeev here, with one additional note.

We have chosen to deprecate features, including ext/mysql. If we now
decide not to remove some of them for 7, we may just remove the
deprecation flag as we are going to support them for the next decade
as well, whether we like it or not.

From the distros/pecl vs core, it is in my humble opinion, a non
issue. Most of the major applications support alternative drivers now,
including the most conservative ones like Wordpress (it is not badly
meant, only a a statement about the situation). Distros tend to enable
by default what the core provides or enables by default. PHP7 will be
no different. Keeping it forever won't help. Removing it may not help
as much as we wish but it will be a clear, loud and unambiguous
signal, which is a good step forward.

I also agree to have more options to vote on. Mass voting may hide
something most of us won't notice.

I also like to discuss what we do for the deprecated features we won't
remove. Keeping the deprecated flags for the sake of keeping it sounds
not so good.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #77909 — Lester Caine — 2014-10-13T07:06:16+00:00

URL: https://externals.io/message/77882#77909 · In reply to: #77905

> > […]
> 
> - The behaviour of # as comments in earlier versions seems to have been
> a side-effect of something else, rather than a deliberate feature. In
> fact, it was possible to have a key starting with #, but a line starting
> # that had no = was silently discarded. [4]

Are there any examples where # is used in distributed ini files?
Is this something that is related to someone's particular preference in
style which a particular distribution path has changed every ; to # as a
quick scan across my entire server base shows no cases where it is used.
Certainly some projects have changed comment coding style in the code
and irritatingly dropped docblock in favour of something else but I've
not see any example of # based ini comments?

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

---

## #77910 — Rowan Collins — 2014-10-13T08:29:40+00:00

URL: https://externals.io/message/77882#77910 · In reply to: #77909

>
> > […]
>been
> > […]
>starting
> > […]
>
>Are there any examples where # is used in distributed ini files?
>Is this something that is related to someone's particular preference in
>style which a particular distribution path has changed every ; to # as
>a
>quick scan across my entire server base shows no cases where it is
>used.
>Certainly some projects have changed comment coding style in the code
>and irritatingly dropped docblock in favour of something else but I've
>not see any example of # based ini comments?

Based on the above, I think what happened is that people had used # for blocks of explanation, and ; for commented out values.

While hunting down what happened, I did find some downstream bugs from one Linux distro removing # comments in reaction to the deprecation notices, so this certainly wasn't just a localised mistake.

---

## #77911 — Julien Pauli — 2014-10-13T09:50:05+00:00

URL: https://externals.io/message/77882#77911 · In reply to: #77908

> 
>
> > […]
>
> I have to agree with Zeev here, with one additional note.
>
> We have chosen to deprecate features, including ext/mysql. If we now
> decide not to remove some of them for 7, we may just remove the
> deprecation flag as we are going to support them for the next decade
> as well, whether we like it or not.

I'm +1 with that idea :-)

>
> From the distros/pecl vs core, it is in my humble opinion, a non
> issue. Most of the major applications support alternative drivers now,
> including the most conservative ones like Wordpress (it is not badly
> meant, only a a statement about the situation). Distros tend to enable
> by default what the core provides or enables by default. PHP7 will be
> no different. Keeping it forever won't help. Removing it may not help
> as much as we wish but it will be a clear, loud and unambiguous
> signal, which is a good step forward.

Yep, this would clearly show our position.
After that, distros of course do what they want.


Julien

---

## #77912 — Dmitry Stogov — 2014-10-13T10:29:06+00:00

URL: https://externals.io/message/77882#77912 · In reply to: #77886

Note, that once we move extension outside of main source tree, only
extension maintainers (if any) will support them.

According to the voting process, I think it makes sense to vote for each
feature separately.

Thanks. Dmitry.






> > […]
> to
> > […]
> by-reference),
> > […]
> handle
> > […]
> removing
> > […]
> time
> > […]
>
> Keep in mind though that it would be mostly symbolic. The majority of
> users get their PHP and extensions from distros. And distros have been
> separating out core-bundled extensions for a decade now. Users have
> absolutely no idea whether their php-mysql package comes from core or from
> pecl, nor do they care. So, unbundling it on our side will have close to
> zero impact on its use. In fact, in a weird way it might actually help make
> people continue to use it because if we unbundle it and stick it in pecl we
> would obviously not have it spew out 'deprecated' notices like we do as of
> 5.5. I mean, we still could, of course, but it would be weird having a
> non-core pecl extension declare itself deprecated.
>
> I am not against unbundling it, I just don't think it will achieve what
> you hope it will.
>
> -Rasmus

---

## #77914 — Jan Ehrhardt — 2014-10-13T12:10:28+00:00

URL: https://externals.io/message/77882#77914 · In reply to: #77912

Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400):
>Note, that once we move extension outside of main source tree, only
>extension maintainers (if any) will support them.

In the ext/mysql case this will be a bit uncomfortable. If you compile
PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of
the functionality of ext/mysql is used. What if mysqlnd drifts away from
supporting ext/mysql?

Jan

---

## #77915 — Pierre Joye — 2014-10-13T12:21:24+00:00

URL: https://externals.io/message/77882#77915 · In reply to: #77914

>
> Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400):
> > […]
>
> In the ext/mysql case this will be a bit uncomfortable. If you compile
> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of
> the functionality of ext/mysql is used. What if mysqlnd drifts away from
> supporting ext/mysql?

It is more the other way 'round.

Mysql being not updated to support latest core change. Which may happen,
and I would have no issue with that if we choose to remove it.

Keeping in mind that we talk about 7 here. So users still have something
like at least 3 years in front of them, 4 if we do a 5.7.

---

## #77918 — Jan Ehrhardt — 2014-10-13T12:46:32+00:00

URL: https://externals.io/message/77882#77918 · In reply to: #77915

Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
>
> > […]
>
>It is more the other way 'round.
>
>Mysql being not updated to support latest core change. Which may happen,
>and I would have no issue with that if we choose to remove it.

OK, maybe I should have said 'what if mysqlnd and ext/mysql drift
apart?' But it still feels uncomfortable. Will it be considered a
BC-break if, say, PHP 7.1 changes something in mysqlnd and ext/mysqli
that is also being used by pecl/mysql?

Jan

---

## #77916 — johannes.schlueter@oracle.com — 2014-10-13T12:48:25+00:00

URL: https://externals.io/message/77882#77916 · In reply to: #77914

> In the ext/mysql case this will be a bit uncomfortable. If you compile
> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of
> the functionality of ext/mysql is used. What if mysqlnd drifts away from
> supporting ext/mysql?

Independently from moving ext/mysql to PECL or not I don't see this
happen in the foreseeable future. I'm quite sure that as long as there
are this huge number of forum posts, applications, ... using mysql_*
this will be kept working. While I support anything teaching users of
alternatives ...

johannes

(This is no legal commitment from Oracle or anything like that)

---

## #77920 — Pierre Joye — 2014-10-13T13:41:01+00:00

URL: https://externals.io/message/77882#77920 · In reply to: #77918

>
> Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
> > […]
from
> > […]
>
> OK, maybe I should have said 'what if mysqlnd and ext/mysql drift
> apart?' But it still feels uncomfortable. Will it be considered a
> BC-break if, say, PHP 7.1 changes something in mysqlnd and ext/mysqli
> that is also being used by pecl/mysql?

Changes in core happens all the time. It is the responsibility of the
external extension maintainers to update their code.

That being said, having mysql in pecl should really not mean that its
maintainers should keep it alive forever. Users willing (for whatever
reasons) to keep using it, can keep using 5.x. But it is not our call, but
the maintainers.

---

## #77946 — Stas Malyshev — 2014-10-14T06:02:30+00:00

URL: https://externals.io/message/77882#77946 · In reply to: #77911

Hi!

> > […]

I don't see how this follows. We may keep them deprecated (which means -
don't use this, it's bad idea) but not remove them to support older
code. Deprecated doesn't have to mean "we will mandatory remove it in
the next version", it may also mean "we no longer think this is a good
idea, please move on from it".

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

## #77947 — Stas Malyshev — 2014-10-14T06:06:34+00:00

URL: https://externals.io/message/77882#77947 · In reply to: #77882

Hi!

I would say we should choose according to the following criteria:

1. Is anybody likely to use it, and if so, will dropping it impede
adoption significantly?
2. Would using it get you into some trouble you can't see easily?
3. How easy it's to detect that something is broken due to BC change?

According to this, I think it would be really good to do this:

- move mysql and ereg out to PECL (disros can bundle them anyway, and
pecl is available for all self builders so adoption won't be hurt much).
- drop incompatible $this context calls (probably seriously messed up code)
- drop magic quotes stuff (if the code relies on magic quotes, something
is seriously wrong). However, I'd consider keeping the get function
(always false) to keep code that checks for it running. It wouldn't
really hurt anybody I think.
- drop dl on FPM - this can lead to some bad crashes
- drop `preg_replace()` eval - it's a security problem waiting to happen
-

I think it can be problematic for:

- # style comments in ini files, it's harder to detect and fix and as
far as I can see, # doesn't hurt anybody


For the rest, don't really have a strong opinion but agree with Zeev on
each function being removed gets upgrade barrier a little higher and
adds more people to the list of "can not upgrade, need code working".

With ini settings, it's a bit easier since one ini edit fixes everything
on the server, no need to check millions of lines of code. However, if
we just drop them it would be hard to detect that these no longer work,
maybe we should produce an error if those are used?

Same for removing options from stream context - in general, if the
option stopped working, I think it's better to let the user know.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

Next page: https://externals.io/message/77882.md?page=2