[RFC] Deprecations for PHP 7.2

8 years ago by Christoph M. Becker — view source

unread

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more controversial
-- please share your specific concerns.

Thanks, Nikita! I'm generally in favor of such clean up.

The only exception would be features which have only been available as
of PHP 7, currently only assertion expressions. Deprecating assertion
strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2
compatible code, even though 7.2 GA is supposed to be released in
December 2017, whereas there'll be security support for 5.6 until end of
2018[1].

[1] http://php.net/supported-versions.php

--
Christoph M. Becker

8 years ago by Nikita Popov — view source

unread

On Fri, Nov 18, 2016 at 6:45 PM, Christoph M. Becker cmbecker69@gmx.de
wrote:

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some
recently
discussed topics (each, binary strings) -- I'm fine with dropping these
if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more
controversial
-- please share your specific concerns.
Thanks, Nikita! I'm generally in favor of such clean up.

The only exception would be features which have only been available as
of PHP 7, currently only assertion expressions. Deprecating assertion
strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2
compatible code, even though 7.2 GA is supposed to be released in
December 2017, whereas there'll be security support for 5.6 until end of
2018[1].

[1] http://php.net/supported-versions.php

This is a reasonable concern. My opinion on assert() and PHP 5 vs PHP 7 is
basically this: You can use assert() the same way in PHP 5 as you do in PHP

Assertion expressions are supported in PHP 5. The only difference is
that it's not zero-cost and error reporting is slightly worse. And well,
PHP 5 being slower than PHP 7 is kinda the case whether you use assertions
or not. If you use PHP 5, performance is clearly your primary concern.

Thanks,
Nikita

8 years ago by Kalle Sommer Nielsen — view source

unread

Hi Nikita

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more controversial
-- please share your specific concerns.

Awesome list, thanks for your work. I got a couple of things to maybe
consider adding:

arg_separator.output/input -- Do we really need an ini to define
these, can't they be baked in or something? (I did not look at the
code)
auto_prepend/auto_append_file directives, I would be amazed if there
couldn't be some optimization complications with those too
register_argv_argc -- deprecate for non CLI?

Might have other things to add later on, these are just what I had in
mind so far

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Christoph M. Becker — view source

unread

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:
I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more controversial
-- please share your specific concerns.
Awesome list, thanks for your work. I got a couple of things to maybe
consider adding:

arg_separator.output/input -- Do we really need an ini to define
these, can't they be baked in or something? (I did not look at the
code)

See also a recent discussion on comp.lang.php:
https://groups.google.com/forum/#!topic/comp.lang.php/wHi0skD_gTc.

TL;DR: these ini settings may cause quite some confusion (note that the
OP is a long-term PHP developer), but removing them might cause
considerable BC breakage. We have to be very careful here, IMHO.

--
Christoph M. Becker

8 years ago by Yasuo Ohgaki — view source

unread

Hi all,

auto_prepend/auto_append_file directives

auto_prepend/append_file is handy to check application
performance/statistical information such as memory usage while
development and/or testing, for example. Do these harm any other than
shooting their own foot?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

8 years ago by Kalle Sommer Nielsen — view source

unread

2016-11-19 1:05 GMT+01:00 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi all,

auto_prepend/auto_append_file directives

auto_prepend/append_file is handy to check application
performance/statistical information such as memory usage while
development and/or testing, for example. Do these harm any other than
shooting their own foot?

Maybe not so much, but I'd like to hear any impact they could have on
optimization much like some of the features in the RFC is mentioned to
be problematic. I did used to use those directives for similar things,
but it was a decade ago :/

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Jan Ehrhardt — view source

unread

Nikita Popov in php.internals (Fri, 18 Nov 2016 15:55:23 +0100):

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

The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings)

I must have missed the discussion about each(). And this really
surprised me:

The each() function is inferior to foreach in pretty much every
imaginable way, including being more than 10 times slower.

But it is mentioned in a 9-year old comment in the manual:
https://php.net/manual/en/function.each.php#75692

A quick grep in my Drupal7 source code showed that not everybody is
aware of that. For instance, even the views module use a list() = each()
construction:
http://cgit.drupalcode.org/views/tree/includes/view.inc#n1740
This means that at least 800,000 sites use list() = each() at the
moment.

I am fine with deprecation, but this may be more wide spread than one
might assume.

Jan

8 years ago by Tony Marston — view source

unread

"Nikita Popov" wrote in message
news:CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com...

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.

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

The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more controversial
-- please share your specific concerns.

Thanks,
Nikita

I am against the removal of the $errorcontext argument of error handler as
this has been a valuable part of my error handler for over ten years.
Whenever trigger_error() is called with a fatal error I write all available
details to a log file as well as sending an email. In order to obtain
additional data I use errorcontext to determine the following:

a) Was it called from a function or an object? For this I use code such as
the following:

if (isset($errcontext['this']) AND is_object($errcontext['this'])) {

b) If it was called from an object, was it one of my database objects? If
yes, then obtain some extra information using code such as the following:

    // retrieve error details from DML object
    if (method_exists($errcontext['this'], 'getQuery')) {
        $query  = $errcontext['this']->getQuery();
    } // if
    if (method_exists($errcontext['this'], 'getErrorNo')) {
        $errno  = $errcontext['this']->getErrorNo();
    } // if
    if (method_exists($errcontext['this'], 'getErrorString')) {
        $errstr = $errcontext['this']->getErrorString();
    } // if
    if (method_exists($errcontext['this'], 'getErrorString2')) {
        $errstr2 = $errcontext['this']->getErrorString2();
    } // if

Saying that I should stop using $errorcontext and instead use a debugger is
very short sighted. I NEED to have this data available in the error log as
soon as the error happens. In several cases I cannot use a debugger as my
application is running behind a client's firewall and their security
restrictions forbid the use of a debugger from outside of that firewall.

I notice that the reason for this recommendation is "because the $errcontext
can be used to modify all references and objects in the current scope." If
this is the case then why not make $errorcontext read-only so that nothing
can be changed. I can imagine lots of people reading from $errorcontext, but
how many actually write? I certainly don't.

--
Tony Marston

8 years ago by Nikita Popov — view source

unread

On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston
wrote:

> "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er=
> G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com...
>
>
>> Hi internals!
>>
>> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
>> due to time constraints. Now I'd like to propose an extended version for
>> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
>> performance.
>>
>> https://wiki.php.net/rfc/deprecations_php_7_2
>>
>> The RFC combines a number of deprecation and removal proposals. Each one
>> will get a separate 2/3 majority vote. The RFC overlaps with some recently
>> discussed topics (each, binary strings) -- I'm fine with dropping these if
>> someone has a more specific RFC.
>>
>> I expect some of these are no-brainers, while others are more
>> controversial
>> -- please share your specific concerns.
>>
>> Thanks,
>> Nikita
>>
>
> I am against the removal of the $errorcontext argument of error handler as
> this has been a valuable part of my error handler for over ten years.
> Whenever `trigger_error()` is called with a fatal error I write all available
> details to a log file as well as sending an email. In order to obtain
> additional data I use errorcontext to determine the following:
>
> a) Was it called from a function or an object? For this I use code such as
> the following:
>
> if (isset($errcontext['this']) AND is_object($errcontext['this'])) {
>
> b) If it was called from an object, was it one of my database objects? If
> yes, then obtain some extra information using code such as the following:
>
> // retrieve error details from DML object
> if (method_exists($errcontext['this'], 'getQuery')) {
> $query = $errcontext['this']->getQuery();
> } // if
> if (method_exists($errcontext['this'], 'getErrorNo')) {
> $errno = $errcontext['this']->getErrorNo();
> } // if
> if (method_exists($errcontext['this'], 'getErrorString')) {
> $errstr = $errcontext['this']->getErrorString();
> } // if
> if (method_exists($errcontext['this'], 'getErrorString2')) {
> $errstr2 = $errcontext['this']->getErrorString2();
> } // if
>

I'm afraid you're out of luck here :/ This usage will no longer be possible
as of PHP 7.1 -- independently of the deprecation proposed in this RFC.
See: https://3v4l.org/sQBL9

Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be
more precise, whenever $this was used as a CV, rather than implicit UNUSED
operand). As of PHP 7.1 $this is never included in the symbol table. This
change is due to https://wiki.php.net/rfc/this_var.

But! This functionality is still available through `debug_backtrace()`.
That's the correct way of fetching the $this of a parent frame, which
should always work (rather than *sometimes* on PHP < 7.1), and is
independent of the error handling mechanism.

So, to clarify: Is $this the only thing from the error context you're
interested in? Or do you also use all the other variables?

> Saying that I should stop using $errorcontext and instead use a debugger
> is very short sighted. I *NEED* to have this data available in the error
> log as soon as the error happens. In several cases I cannot use a debugger
> as my application is running behind a client's firewall and their security
> restrictions forbid the use of a debugger from outside of that firewall.

> I notice that the reason for this recommendation is "because the
> $errcontext can be used to modify all references and objects in the current
> scope." If this is the case then why not make $errorcontext read-only so
> that nothing can be changed. I can imagine lots of people reading from
> $errorcontext, but how many actually write? I certainly don't.

We can do this for references (i.e., dereference them for the provided
symbol table), but not for objects, because we don't have any way of
enforcing immutability on the language side.

Thanks,
Nikita

7 years ago by Tony Marston — view source

unread

"Nikita Popov" wrote in message
news:CAF+90c91SPFOHiTJGpwTEvZt_Wyk+hTX4-TANTMsshhcTQQVfw@mail.gmail.com...
>
>On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston
>wrote:
>
>> "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er=
>> G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com...
>>
>>
>>> Hi internals!
>>>
>>> I've submitted this RFC for PHP 7.1 previously, but didn't follow
>>> through
>>> due to time constraints. Now I'd like to propose an extended version for
>>> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
>>> performance.
>>>
>>> https://wiki.php.net/rfc/deprecations_php_7_2
>>>
>>> The RFC combines a number of deprecation and removal proposals. Each one
>>> will get a separate 2/3 majority vote. The RFC overlaps with some
>>> recently
>>> discussed topics (each, binary strings) -- I'm fine with dropping these
>>> if
>>> someone has a more specific RFC.
>>>
>>> I expect some of these are no-brainers, while others are more
>>> controversial
>>> -- please share your specific concerns.
>>>
>>> Thanks,
>>> Nikita
>>>
>>
>> I am against the removal of the $errorcontext argument of error handler
>> as
>> this has been a valuable part of my error handler for over ten years.
>> Whenever `trigger_error()` is called with a fatal error I write all
>> available
>> details to a log file as well as sending an email. In order to obtain
>> additional data I use errorcontext to determine the following:
>>
>> a) Was it called from a function or an object? For this I use code such
>> as
>> the following:
>>
>> if (isset($errcontext['this']) AND is_object($errcontext['this'])) {
>>
>> b) If it was called from an object, was it one of my database objects? If
>> yes, then obtain some extra information using code such as the following:
>>
>> // retrieve error details from DML object
>> if (method_exists($errcontext['this'], 'getQuery')) {
>> $query = $errcontext['this']->getQuery();
>> } // if
>> if (method_exists($errcontext['this'], 'getErrorNo')) {
>> $errno = $errcontext['this']->getErrorNo();
>> } // if
>> if (method_exists($errcontext['this'], 'getErrorString')) {
>> $errstr = $errcontext['this']->getErrorString();
>> } // if
>> if (method_exists($errcontext['this'], 'getErrorString2')) {
>> $errstr2 = $errcontext['this']->getErrorString2();
>> } // if
>>
>
>I'm afraid you're out of luck here :/ This usage will no longer be possible
>as of PHP 7.1 -- independently of the deprecation proposed in this RFC.
>See: https://3v4l.org/sQBL9
>
>Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be
>more precise, whenever $this was used as a CV, rather than implicit UNUSED
>operand). As of PHP 7.1 $this is never included in the symbol table. This
>change is due to https://wiki.php.net/rfc/this_var.
>
>But! This functionality is still available through `debug_backtrace()`.
>That's the correct way of fetching the $this of a parent frame, which
>should always work (rather than *sometimes* on PHP < 7.1), and is
>independent of the error handling mechanism.

The RFC does not specify this, it simply says "use a proper debugger". Will
I still be able to use `debug_backtrace()` to obtain the same information that
is available in $errorcontext?If so, this should be explicitly stated in the
RFC.

>So, to clarify: Is $this the only thing from the error context you're
>interested in? Or do you also use all the other variables?

I use all the other variables as well, but sometimes I need to use
$errorcontext to supply additional information

--
Tony Marston

8 years ago by Rowan Collins — view source

unread

> Hi internals!
>
> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
> due to time constraints. Now I'd like to propose an extended version for
> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
> performance.
>
> https://wiki.php.net/rfc/deprecations_php_7_2
>

Hi Nikita,

I'm interested to see `create_function()` on this list, as one of my first
contributions to the list was suggesting its deprecation, and I didn't
feel there was sufficient consensus to go forward. Thread here:
http://marc.info/?t=138178649200002&r=2&w=2
http://marc.info/?t=138178649200002&r=1&w=2 It's possible the
intervening three years have changed things sufficiently to reconsider,
though.

On a broader note, I would like to restate my desire for some kind of
road map or plan of roughly when 8.0 is expected, to inform decisions on
things like this. Does "deprecate in 7.2" mean removal in 2 years time,
or 5, or 10?

Previously I've been answered with "the Big Feature of 8.0 will be JIT",
but I am not a fan of tying the deprecation and feature policy to
"whenever we happen to have a rewrite of the engine ready"; it muddles
product branding with API versioning. If JIT isn't ready for 10 years,
does that mean we have to wait 10 years to break BC? And if it's ready
in 2018, does that mean everything deprecated in 7.2 has to be
immediately dropped after just one year? Should we decouple the Zend
Engine version from the language version, and use separate semantic
versions for each?

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Kalle Sommer Nielsen — view source

unread

Hi Rowan

2016-11-19 18:23 GMT+01:00 Rowan Collins rowan.collins@gmail.com:

On a broader note, I would like to restate my desire for some kind of road
map or plan of roughly when 8.0 is expected, to inform decisions on things
like this. Does "deprecate in 7.2" mean removal in 2 years time, or 5, or
10?

Previously I've been answered with "the Big Feature of 8.0 will be JIT", but
I am not a fan of tying the deprecation and feature policy to "whenever we
happen to have a rewrite of the engine ready"; it muddles product branding
with API versioning. If JIT isn't ready for 10 years, does that mean we have
to wait 10 years to break BC? And if it's ready in 2018, does that mean
everything deprecated in 7.2 has to be immediately dropped after just one
year? Should we decouple the Zend Engine version from the language version,
and use separate semantic versions for each?

I kinda liked the model we had back in the late 5.x series (namely
starting with 5.3 from 2009), although that was before we had a
release plan decided, it did make a lot of sense to deprecate some
features, of course taking into consideration what they are and the
impact they have. The model we had was deprecate in x.z, then remove
in z+1, things to this list include safe_mode, register_globals for
example, not that these were as ground breaking changes because of the
movement to use PHP5. I think create_function(), as mentioned, is a
feature worthy of being deprecated in one version, then removed in the
next. Like you also mention, major versions are really rare and I
think it should be kept that way, or at least until we reach a point
where we literally cannot improve PHP7 anymore without major changes,
such as the case for PHP 5.6 was. Side note, I still think that with
the amount of work, changes and features, PHP 5.3 was almost worth the
role of being a major version, but lets not side track the subject ;-)

With our current model, that means that when we deprecate something,
users got a year to upgrade their code, if they are bleeding edge
users, but most are likely not, so they have more time to upgrade the
code, and to be fair, we try to do the removals in moderate parts to
not overwhelm developers who are upgrading their code, or projects
that supports a wide range of PHP versions, such as phpB which support
PHP 5.3.0+. After that 1 year, we do offer 2 years additional security
fixes support, so I think that there is more than enough time for our
community to update their code bases. PHP 7.0 was a great success
externally for migration.

So to answer your question in a short without much more rambling: I
think we should deprecate in x.z, then remove in x.z+1 depending on
the feature, if we say "Oh let's remove this in the next major",
chances are that major won't even be branches for years, and at that
time, it could be forgotten.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Marco Pivetta — view source

unread

So to answer your question in a short without much more rambling: I
think we should deprecate in x.z, then remove in x.z+1 depending on
the feature, if we say "Oh let's remove this in the next major",
chances are that major won't even be branches for years, and at that
time, it could be forgotten.

That will end up breaking the "expected" (because it's not that way anyway,
but almost) SemVer approach, diminishing the trust from consumers in any
kind of upgrade.
Most of the current open-source libs out there are trying to push for
SemVer - having PHP not following that seems like a huge mess to me.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

8 years ago by Christoph M. Becker — view source

unread

So to answer your question in a short without much more rambling: I
think we should deprecate in x.z, then remove in x.z+1 depending on
the feature, if we say "Oh let's remove this in the next major",
chances are that major won't even be branches for years, and at that
time, it could be forgotten.

That will end up breaking the "expected" (because it's not that way anyway,
but almost) SemVer approach, diminishing the trust from consumers in any
kind of upgrade.
Most of the current open-source libs out there are trying to push for
SemVer - having PHP not following that seems like a huge mess to me.

Our release process[1] explicitly forbids breaking userland API between
x.y.z and x.y+1.z.

[1] https://wiki.php.net/rfc/releaseprocess

--
Christoph M. Becker

8 years ago by Kalle Sommer Nielsen — view source

unread

Hi Marco

2016-11-19 18:56 GMT+01:00 Marco Pivetta ocramius@gmail.com:

That will end up breaking the "expected" (because it's not that way anyway,
but almost) SemVer approach, diminishing the trust from consumers in any
kind of upgrade.
Most of the current open-source libs out there are trying to push for SemVer

having PHP not following that seems like a huge mess to me.

I don't think a SemVer approach will work for PHP in its current
state, not to say that it won't but the way that some of these things
are implemented, it makes complications for further internal
improvements that comes with each major/minor release.

Take the "Forbid Dynamic Scope Introspection" RFC you voted yes to,
which is implemented in PHP 7.1, sure, this one in particular is on
the path down to pandora's PHP edge case box, but without it we would
have lost speed gain optimizations (faster PHP by upgrading) and have
to stick around with code that could lead to pitfalls, hard to debug
code or nasty crashes. I do understand that we have to draw a line in
what is sensible to deprecate and remove in favor of what and when,
but keep in mind how large a userbase PHP serves, hundreds of millions
of websites, millions of developers and yet we are maybe about 20
active developers who contribute code to PHP's internals on a regular
basis. Time, resources and energy for keeping things in closed state
for so long where we cannot change anything is not fun or motivating
for contributing.

(And I would rather not that PHP felt into a version scheme similar to
that of Chrome where in December we could have PHP 42.0.)

[1] https://wiki.php.net/rfc/forbid_dynamic_scope_introspection

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Rowan Collins — view source

unread

On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen <kalle@php.net
mailto:kalle@php.net> wrote:
So to answer your question in a short without much more rambling: I
think we should deprecate in x.z, then remove in x.z+1 depending on
the feature, if we say "Oh let's remove this in the next major",
chances are that major won't even be branches for years, and at that
time, it could be forgotten.
That will end up breaking the "expected" (because it's not that way
anyway, but almost) SemVer approach, diminishing the trust from
consumers in any kind of upgrade.
Most of the current open-source libs out there are trying to push for
SemVer - having PHP not following that seems like a huge mess to me.

I agree with this, to an extent. If we formally disavow any meaning of
"major release" other than branding, the expectation is less of an issue
in itself. But it's interesting that PostgreSQL is moving to a 2-part
version numbering: instead of the annual feature releases being 9.7.0,
9.8.0, 9.9.0 etc, they will be 10.0, 11.0, 12.0, thus eliminating debate
about which releases should be classed as "major".

Like you also mention, major versions are really rare and I
think it should be kept that way, or at least until we reach a point
where we literally cannot improve PHP7 anymore without major changes,
such as the case for PHP 5.6 was.

What is a "major change", if you want to abandon the link to
compatibility? Do you mean "headline-grabbing feature", i.e. versioning
as a brand?

With our current model, that means that when we deprecate something,
users got a year to upgrade their code, if they are bleeding edge
users, but most are likely not, so they have more time to upgrade the
code

This is a recipe for massive version fragmentation. When x.3 comes out,
some people will be stuck on x.0, some on x.1, some on x.2, etc; library
authors won't be able to take advantage of the features introduced in
x.3, and everyone has to remember just what's new in each release.

I actually think major releases should be more common, to reduce the
temptation to "bend" the rules, and break compatibility early. The
policy could be as simple as "every major release will have between 3
and 5 minor releases". Then the earliest release of 8.0 would be after
7.2 (late 2018 / early 2019), and the latest would be after 7.4 (late
2020 / early 2021).

Having a road map in advance also means you can branch early, break
things, and know how long you're going to have to maintain that branch for.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Christoph M. Becker — view source

unread

On a broader note, I would like to restate my desire for some kind of
road map or plan of roughly when 8.0 is expected, to inform decisions on
things like this. Does "deprecate in 7.2" mean removal in 2 years time,
or 5, or 10?

Previously I've been answered with "the Big Feature of 8.0 will be JIT",
but I am not a fan of tying the deprecation and feature policy to
"whenever we happen to have a rewrite of the engine ready"; it muddles
product branding with API versioning. If JIT isn't ready for 10 years,
does that mean we have to wait 10 years to break BC? And if it's ready
in 2018, does that mean everything deprecated in 7.2 has to be
immediately dropped after just one year? Should we decouple the Zend
Engine version from the language version, and use separate semantic
versions for each?

IMHO, we should consider introducing a fixed schedule for major releases
(say, every 4 years).

--
Christoph M. Becker

8 years ago by Kalle Sommer Nielsen — view source

unread

Hi Christoph

2016-11-19 19:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

IMHO, we should consider introducing a fixed schedule for major releases
(say, every 4 years).

I think that should depend on a case by case basis for when we are
working towards a new version, a lot of awesome work are already in
for master that won't be out for at least another year. At the point
when we pick RMs for the next branch, then we have in the past
evaluated the scope of changes currently planned to be included, what
is currently in and what the magical guys at Zend are doing and decide
there. Having a fixed, forced major version does not sound that great
if we do not have something awesome that could only ever exist in a
new major version,

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Christoph M. Becker — view source

unread

Hi Kalle!

2016-11-19 19:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

IMHO, we should consider introducing a fixed schedule for major releases
(say, every 4 years).

I think that should depend on a case by case basis for when we are
working towards a new version, a lot of awesome work are already in
for master that won't be out for at least another year. At the point
when we pick RMs for the next branch, then we have in the past
evaluated the scope of changes currently planned to be included, what
is currently in and what the magical guys at Zend are doing and decide
there. Having a fixed, forced major version does not sound that great
if we do not have something awesome that could only ever exist in a
new major version,

But this short-dated decision on whether next will be a major or minor
is exactly the problem. Consider, for instance, this RFC which targets
7.2 for deprecation and 8.0 for removal. What if we decide in some
month that there'll be no 7.2, but rather 8.0 will be next? Would we
remove the features without a deprecation phase, or would we deprecate
them for 8.0 and remove later? Either way, I'm pretty sure that we
would have a lenghty discussion, and might even need another vote. And
at least some RFCs and documentation would have to be fixed.

At the very least I would suggest to decide whether the next version but
one will be major or minor at the same time we tag the first alpha of
the next version. I.e. this decision would had been made months ago,
and actually all RFCs I've read assume that PHP 7.2 will be next.

--
Christoph M. Becker

8 years ago by Kalle Sommer Nielsen — view source

unread

Hi Christoph

2016-11-19 19:56 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

Hi Kalle!

But this short-dated decision on whether next will be a major or minor
is exactly the problem. Consider, for instance, this RFC which targets
7.2 for deprecation and 8.0 for removal. What if we decide in some
month that there'll be no 7.2, but rather 8.0 will be next? Would we
remove the features without a deprecation phase, or would we deprecate
them for 8.0 and remove later? Either way, I'm pretty sure that we
would have a lenghty discussion, and might even need another vote. And
at least some RFCs and documentation would have to be fixed.

That is a valid concern I agree. I just have a hard time wrapping my
head around what if we don't have anything ground breaking for a major
that I would expect in any major, what differences does it then make
for it to not be a minor. I'm a little skeptical on having a pre
determined plan, I do see pros/cons for both sides of the argument and
I reckon the point you raised to be of a possible con of not having a
pre determined plan.

But I do kinda like Rowan's idea of a major within x or y releases
from last major. Gonna think about this for a bit...

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Rowan Collins — view source

unread

Having a fixed, forced major version does not sound that great if we
do not have something awesome that could only ever exist in a new
major version

Again, you're looking at version numbers as primarily a branding thing
("something awesome") rather than a technical thing ("something that
breaks compatibility").

I think this is the biggest thing that the formal SemVer standard forces
a developer to accept: you don't get to choose when something "deserves"
a major version number, you MUST increment it when you break
compatibility. As the FAQ on semver.org says, if you reach 42.0.0 very
rapidly under SemVer, that's because your API isn't stable; pretending
some of those versions are minor releases is just masking the problem.

If we adopted SemVer (which I'm not particularly proposing, just
offering as comparison) there is absolutely zero chance that 4 years
would pass without us having a single change which warranted a major
version bump. As soon as you have one feature marked deprecated, then
the release where that is removed is a major release, regardless of what
else it has.

That's why I mentioned divorcing the Engine and Language versions: if we
don't want to brand something as "PHP 8" unless it's got shinies, then
you could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm
not sure that split does quite work, but it would at least make explicit
the difference between brand version and compatibility version.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Kalle Sommer Nielsen — view source

unread

2016-11-19 22:56 GMT+01:00 Rowan Collins rowan.collins@gmail.com:

Again, you're looking at version numbers as primarily a branding thing
("something awesome") rather than a technical thing ("something that breaks
compatibility").

Yes because that has been our past model for a long time. Like I
mentioned, PHP 5.3 should probably have been a major considering the
changes it did. It wasn't until PHP 5.3 that we introduced
E_DEPREPCATED and actively started taking out problematic features
which in the past had caused issues with the usual group of people who
don't care to read the manual, so we gave those features a little
longer life span while informing the developers that we are gonna
remove it.

Basically before we started to get all political of things, which is
both good and bad, then a new x+1.z or x.z+1 version was based off
having a large number of features that branded that version as a
whole, and I think that is perfectly fine.

I think this is the biggest thing that the formal SemVer standard forces a
developer to accept: you don't get to choose when something "deserves" a
major version number, you MUST increment it when you break compatibility. As
the FAQ on semver.org says, if you reach 42.0.0 very rapidly under SemVer,
that's because your API isn't stable; pretending some of those versions are
minor releases is just masking the problem.

If we were to rename past releases to a scheme by SemVer, then that
would pretty much have been a yearly major, that is extremely poor
versioning in my opinion when we retrain such a high backwards
compatibility rate otherwise. I don't like the thought that PHP 5.4
could have been PHP 6 just because we removed safe_mode, that was
deprecated in 5.3. That would be a disappointing reason just to go for
a new major.

I think the main reason we reserve major versions, and have in the
past is that the internal API is very compatible across minor
versions, 5.x even contained macros for PHP4 extensions to be mostly
compatible or even loadable pre 4.3 extensions for a long time if I
remember correctly (I think it was Julien that removed that in 5.5).

If we adopted SemVer (which I'm not particularly proposing, just offering as
comparison) there is absolutely zero chance that 4 years would pass without
us having a single change which warranted a major version bump. As soon as
you have one feature marked deprecated, then the release where that is
removed is a major release, regardless of what else it has.

Same as above, I dislike this rapid jumping in versioning. Though this
is my personal opinion, for me as a Core Developer of PHP, I prefer
this scheme as it makes sense to me as it is pretty much what it
always has been. Taking Chrome, or well Blink as I use Opera, as an
example, I don't see the big point in that every few weeks I get a new
major version of my browser because some handy new feature was added,
might as well have been a minor release, like Opera used to be in the
Presto days.

That's why I mentioned divorcing the Engine and Language versions: if we
don't want to brand something as "PHP 8" unless it's got shinies, then you
could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm not sure
that split does quite work, but it would at least make explicit the
difference between brand version and compatibility version.

I don't think that will work as most people when you say the Zend
Engine that is not into the PHP.net project will maybe know that its
the core of PHP, but nothing more about it so I don't think it makes
much sense to suddenly start label releases as such. PHP for almost
two decades have only been released with Zend Engine and they are so
coupled together today that I doubt you can build LibZend standalone
anymore.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

8 years ago by Rowan Collins — view source

unread

2016-11-19 22:56 GMT+01:00 Rowan Collins rowan.collins@gmail.com:

Again, you're looking at version numbers as primarily a branding thing
("something awesome") rather than a technical thing ("something that breaks
compatibility").
Yes because that has been our past model for a long time. Like I
mentioned, PHP 5.3 should probably have been a major considering the
changes it did.

Agreed that it's the past model, and agreed that 5.3 was misnamed
whichever way you look at it.

The fact that something used to be done a particular way doesn't mean
that was the best way, though. It's also not what the current release
process specifies, in my opinion.

It wasn't until PHP 5.3 that we introduced
E_DEPREPCATED and actively started taking out problematic features
which in the past had caused issues with the usual group of people who
don't care to read the manual, so we gave those features a little
longer life span while informing the developers that we are gonna
remove it.

Basically before we started to get all political of things

I'm not sure what you mean by "political". The big challenge which comes
up again and again, is that take up of new versions of PHP is low. You
can blame the users for that if you like, but the reality is there's no
point rushing your shiny feature into a release that 90% of the user
base won't install.

Well-publicised deprecations, and a strict adherence to compatibility,
build trust that upgrading won't be a major headache, meaning new
features actually get to users faster. And to return to the topic at
hand, knowing how long something will be deprecated before it's removed
helps people plan ahead.

If we were to rename past releases to a scheme by SemVer, then that
would pretty much have been a yearly major, that is extremely poor
versioning in my opinion when we retrain such a high backwards
compatibility rate otherwise.

If every release contained breaking changes, then the release process
RFC has failed. It would be extremely poor versioning not because we'd
somehow run out of version numbers, but because it means we've made
upgrading harder than it should be.

Let me quote that SemVer FAQ in full:

/Q: //If even the tiniest backwards incompatible changes to the public
API require a major version bump, won’t I end up at version 42.0.0
very rapidly?//
//
//A: This is a question of responsible development and foresight.
Incompatible changes should not be introduced lightly to software that
has a lot of dependent code. The cost that must be incurred to upgrade
can be significant. Having to bump major versions to release
incompatible changes means you’ll think through the impact of your
changes, and evaluate the cost/benefit ratio involved./

In reality, we had two very successful minor releases after the release
process was agreed: 5.5, and 5.6. I think 7.1 has bent the rules, and I
think that's a shame.

I don't like the thought that PHP 5.4
could have been PHP 6 just because we removed safe_mode, that was
deprecated in 5.3. That would be a disappointing reason just to go for
a new major.

Agreed, so the answer would be not to remove it yet! If it was really
that urgent to remove the feature, then yes, bump the version number to
say so; if it could wait for one more minor release, then let it wait.

It's an odd example though, because for me by far the biggest break in
5.4 was the removal of call-time pass-by-reference, which was widely
used, and very fiddly to remove. But the story of 5.3 and 5.4 is
inextricably tied up with the failure of 6.0, so we can come up with all
sorts of "what if" scenarios and prove very little about the present and
future.

Same as above, I dislike this rapid jumping in versioning. Though this
is my personal opinion, for me as a Core Developer of PHP, I prefer
this scheme as it makes sense to me as it is pretty much what it
always has been.

That's fine, that's what I mean by "version number as branding". But if
we go down that route, we should drop all reference to major versions in
our deprecation and compatibility policy, because that's a fundamentally
different meaning of "major".

For instance, we could have a fixed duration of deprecation, say
deprecated for 2 versions, removed in the next. So any features
deprecated in 2017's release would be removed in 2019's release,
regardless of its version number. In 2018, further features could be
deprecated, to be removed in 2020, and so on.

That's why I mentioned divorcing the Engine and Language versions
I don't think that will work as most people when you say the Zend
Engine that is not into the PHP.net project will maybe know that its
the core of PHP, but nothing more about it so I don't think it makes
much sense to suddenly start label releases as such.

Sure, I was just brainstorming alternative solutions, since we seem to
have very different ideas of what the version number is there for.
Ignoring "Zend Engine" in particular, think about Windows prior to 10:
the internal (kernel) version number had strict rules, and the marketers
could make up whatever name they liked, meaning Windows 7 and 8 were
both internally 6.x.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Alice Wonder — view source

unread

I'm not sure what you mean by "political". The big challenge which comes
up again and again, is that take up of new versions of PHP is low. You
can blame the users for that if you like, but the reality is there's no
point rushing your shiny feature into a release that 90% of the user
base won't install.

For the perspective of a user on this -

I always skip a major version. I'm running 5.6.x on my productions, and
preparing for 7.1 I am running 7.1.0RC on one test server and my
workstation. I'll probably run 7.1 on production fairly soon after
release but likely skip 7.2.

I skip because once I have a web application deployed, I'm not looking
to change it for awhile, security updates sure but I don't need to run
the latest major release when the release I have works fine.

I suspect many are the same way, and I don't see that as a bad thing.

Releases no longer maintained by upstream obviously should not be run,
but if the release one has works for the purpose, what problem is solved
by upgrading to latest major release? It's time consuming and expensive
because there is always code that needs to be changed and tested.

8 years ago by Derick Rethans — view source

unread

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I wouldn't deprecate things that 1. have no replacement, 2. are very
much in use, or 3. are harmless.

__autoload is one of group (2). I think this is used a lot, and would
not want to deprecate this until PHP 8.

I also do not see why (binary) should be removed, as it fits in category

In general, I think you should have a good reason why to remove them,
and just "it's not what we suggest you use" is not good enough. It
should be a general bad thing, before it should be considered for
removal.

Right now, the only thing I can think of is removing
mbstring.func_overload.

For ini settings, you should not throw a deprecation warning if the
setting is set to off. This covers mbstring.func_overload , but it
seems you have changed that since I read this RFC for the first time.

cheers,
Derick

8 years ago by Daniel Morris — view source

unread

__autoload is one of group (2). I think this is used a lot, and would
not want to deprecate this until PHP 8.

Agreed, I still think this is used widely, it would be fine to have it
throw an E_DEPRECATED in 7.2 and removed in 8.0. Upgrading to not use
__autoload would be trivial.

I also do not see why (binary) should be removed, as it fits in category

Whilst (binary) may be harmless, it's also pointless, since it's just an
alias for (string) – I don't think it has wide-enough usage to worry
about deprecating it sooner rather than later.

--
Daniel Morris
daniel@honestempire.com

8 years ago by Rowan Collins — view source

unread

__autoload is one of group (2). I think this is used a lot, and would
not want to deprecate this until PHP 8.
Agreed, I still think this is used widely, it would be fine to have it
throw an E_DEPRECATED in 7.2 and removed in 8.0. Upgrading to not use
__autoload would be trivial.

Note that this would be a "yes" vote, where Derick was implying he would
vote "no". I quote:

The RFC proposes to deprecate the listed functionality in PHP 7.2 and
remove it no later than in PHP 8.0.

Regards,

--
Rowan Collins
[IMSoP]

8 years ago by Kalle Sommer Nielsen — view source

unread

Hi

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2

I was actually gonna make an RFC for this, but the (real) cast and
is_real() function, our third alias for float/double/real could be
added to the deprecation list. It doesn't make much sense to keep
three aliases where one of them is rarely used in "real" life
applications.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Kalle Sommer Nielsen — view source

unread

Hi Nikita

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2

Another one could be php_sapi_name() which returns a constant value,
from which we already have available; PHP_SAPI

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Maciej Sobaczewski — view source

unread

Hi Kalle

W dniu 10.12.2016 o 15:16, Kalle Sommer Nielsen pisze:

Hi Nikita

2016-11-18 15:55 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:
Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
Another one could be php_sapi_name() which returns a constant value,
from which we already have available; PHP_SAPI

php_sapi_name() is not unique here - as far as I can tell pi() works the
same way. And it's not I'm against such deprecations - I just wonder if
we want to make it more general rule for proceeding.

7 years ago by Nikita Popov — view source

unread

Hi internals!

I've submitted this RFC for PHP 7.1 previously, but didn't follow through
due to time constraints. Now I'd like to propose an extended version for
PHP 7.2 and vote on it sooner rather than later to avoid a repeat
performance.
https://wiki.php.net/rfc/deprecations_php_7_2
The RFC combines a number of deprecation and removal proposals. Each one
will get a separate 2/3 majority vote. The RFC overlaps with some recently
discussed topics (each, binary strings) -- I'm fine with dropping these if
someone has a more specific RFC.

I expect some of these are no-brainers, while others are more
controversial -- please share your specific concerns.

Thanks,
Nikita

I would like to proceed to voting on this RFC soon.

There are only two items on this list that I am not entirely certain about:

a) assert() with a string argument: Multiple people pointed out that it
might be too early to deprecate this function. In particular, some Drupal
contributors mentioned that Drupal currently uses assert() with string
arguments as an optimization to avoid executing certain code in production.

I have changed the RFC to clarify that assert() with a string argument will
only throw a deprecation warning if assertions are enabled. As such
projects have a choice between either using the non-string form and
incurring a penalty in production on PHP 5 (my default recommendation), or
using the string form and incurring a penalty in debug mode on PHP >=7.2
(the penalty being caused by deprecation warnings). The latter might be
preferable in some cases, especially as the string form of assert() is
already very slow if assertions are enabled.

b) The $errcontext parameter for the error handler. A few people raised
concerns about this, but on further discussion it always turned out that
they were interested in information provided by debug_backtrace(), not by
$errcontext. I have now added an explicit reference to debug_backtrace() to
the RFC.

I will likely proceed with both deprecations included and let voting decide
on the question.

Regards,
Nikita

7 years ago by Kalle Sommer Nielsen — view source

unread

Hi Nikita

2016-12-21 17:46 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

I will likely proceed with both deprecations included and let voting decide
on the question.

What about adding the mysqli embedded server API to the list? It's
been experimental for so long, and not even been ported to PHP7 (see
ext/mysqli/mysqli_embedded.c), its not supported by mysqlnd (as per
comments in the m4) and never had the /D flag for Windows (or so it
seems).

Regards,
Nikita

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Nikita Popov — view source

unread

Hi Nikita

2016-12-21 17:46 GMT+01:00 Nikita Popov nikita.ppv@gmail.com:

I will likely proceed with both deprecations included and let voting
decide
on the question.

What about adding the mysqli embedded server API to the list? It's
been experimental for so long, and not even been ported to PHP7 (see
ext/mysqli/mysqli_embedded.c), its not supported by mysqlnd (as per
comments in the m4) and never had the /D flag for Windows (or so it
seems).

I don't think this requires deprecation, it can be directly dropped.
Deprecating it would require making it compile first. Given that it doesn't
compile currently, hasn't compiled since the PHP 7 release and there hasn't
been a single complaint, it is safe to say that nobody uses this.

Nikita

7 years ago by netmo.php@gmail.com — view source

unread

(i didn't read the above discussion)

Can we deprecate also the php5-style assert()? It wasn't used a lot anyway.
Thanks :P

7 years ago by Stanislav Malyshev — view source

unread

Hi!

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

Reading through the list, I find several categories:

Completely ok:

(unset) - don't see any sane use case anyway
gmp_random

Can cause breakage but it's ok:

$php_errormsg
__autoload
mbstring.func_overload
parse_str() - people can use it in functions, it doesn't have to be
globals. But it's cleaner with second arg.
$errcontext

Don't see a reason to remove:

(binary) cast and b"" - yes, they are not currently doing anything. But
they don't also hurt anything.

High breakage potential:

each() - I've seen a lot of code using each. Yes, it's not the best way.
A lot of people write code not in absolutely best way but in a way they
like to. Argument about list() proposed in RFC makes little sense to me

since problem is with list() and not each() why each() should be
deprecated because of it? And I certainly object its removal.

create_function() - yes, there are closures now. But there's a lot of
code created when there were none, and that code works, and there's no
reason to break it. I'd probably be OK with deprecation warning but not
with removal.

Special case:
assert() - if the string arg is a security issue, deprecating it
achieves nothing. So I'm not sure I understand the argument for
deprecation - if string assert is a problem we probably should make
assert() construct instead check if assert is used in eval form, not by
argument count?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Alexander Lisachenko — view source

unread

Hi, internals!

I want to propose to deprecate one more weird feature of PHP called
"comparison of different types"
http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.types.

Here you can check one simple example https://3v4l.org/kCOAf to see why it
should be deprecated.

It would be nice to deprecate all comparison operators between different
types and throw an exception later in future version of PHP.

Operators that should be allowed for comparison of different types are the
following: ==, !=, ===, !==, <>.
Operators to deprecate for comparison of different types are the following:

, <, >=, <=, <=>

I also think about deprecation of string/object/array comparison with
operators like greater/less, because it's hard to understand results for
'1000' < '0xabc1' (see https://3v4l.org/o3iLj) or even object comparison
https://3v4l.org/5At1l

Thanks!

2016-12-27 9:52 GMT+03:00 Stanislav Malyshev smalyshev@gmail.com:

Hi!
https://wiki.php.net/rfc/deprecations_php_7_2
Reading through the list, I find several categories:

Completely ok:

(unset) - don't see any sane use case anyway
gmp_random

Can cause breakage but it's ok:

$php_errormsg
__autoload
mbstring.func_overload
parse_str() - people can use it in functions, it doesn't have to be
globals. But it's cleaner with second arg.
$errcontext

Don't see a reason to remove:

(binary) cast and b"" - yes, they are not currently doing anything. But
they don't also hurt anything.

High breakage potential:

each() - I've seen a lot of code using each. Yes, it's not the best way.
A lot of people write code not in absolutely best way but in a way they
like to. Argument about list() proposed in RFC makes little sense to me

since problem is with list() and not each() why each() should be
deprecated because of it? And I certainly object its removal.

create_function() - yes, there are closures now. But there's a lot of
code created when there were none, and that code works, and there's no
reason to break it. I'd probably be OK with deprecation warning but not
with removal.

Special case:
assert() - if the string arg is a security issue, deprecating it
achieves nothing. So I'm not sure I understand the argument for
deprecation - if string assert is a problem we probably should make
assert() construct instead check if assert is used in eval form, not by
argument count?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Alexander Lisachenko — view source

unread

There was small typo in my previous link to object comparison: new one is
https://3v4l.org/tMokY

2016-12-27 14:33 GMT+03:00 Alexander Lisachenko lisachenko.it@gmail.com:

Hi, internals!

I want to propose to deprecate one more weird feature of PHP called
"comparison of different types" http://php.net/manual/en/
language.operators.comparison.php#language.operators.comparison.types.
Here you can check one simple example https://3v4l.org/kCOAf to see why
it should be deprecated.

It would be nice to deprecate all comparison operators between different
types and throw an exception later in future version of PHP.

Operators that should be allowed for comparison of different types are the
following: ==, !=, ===, !==, <>.
Operators to deprecate for comparison of different types are the
following: >, <, >=, <=, <=>

I also think about deprecation of string/object/array comparison with
operators like greater/less, because it's hard to understand results for
'1000' < '0xabc1' (see https://3v4l.org/o3iLj) or even object comparison
https://3v4l.org/5At1l

Thanks!

2016-12-27 9:52 GMT+03:00 Stanislav Malyshev smalyshev@gmail.com:
Hi!
https://wiki.php.net/rfc/deprecations_php_7_2
Reading through the list, I find several categories:

Completely ok:

(unset) - don't see any sane use case anyway
gmp_random

Can cause breakage but it's ok:

$php_errormsg
__autoload
mbstring.func_overload
parse_str() - people can use it in functions, it doesn't have to be
globals. But it's cleaner with second arg.
$errcontext

Don't see a reason to remove:

(binary) cast and b"" - yes, they are not currently doing anything. But
they don't also hurt anything.

High breakage potential:

each() - I've seen a lot of code using each. Yes, it's not the best way.
A lot of people write code not in absolutely best way but in a way they
like to. Argument about list() proposed in RFC makes little sense to me

since problem is with list() and not each() why each() should be
deprecated because of it? And I certainly object its removal.

create_function() - yes, there are closures now. But there's a lot of
code created when there were none, and that code works, and there's no
reason to break it. I'd probably be OK with deprecation warning but not
with removal.

Special case:
assert() - if the string arg is a security issue, deprecating it
achieves nothing. So I'm not sure I understand the argument for
deprecation - if string assert is a problem we probably should make
assert() construct instead check if assert is used in eval form, not by
argument count?

--
Stas Malyshev
smalyshev@gmail.com

7 years ago by Nicolas Grekas — view source

unread

Hi Nikita, hi all,

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

I just realized that in Symfony, we use the $errcontext argument of error
handlers to work around the limitation of __toString not being able to
throw.

Excerpt from
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/ErrorHandler.php#L439
:

                    // Here, we know `trigger_error()` has been called

from __toString().
// HHVM is fine with throwing from __toString() but
PHP triggers a fatal error instead.
// A small convention allows working around the
limitation:
// given a caught $e exception in __toString(),
quitting the method with
// return trigger_error($e, E_USER_ERROR); allows
this error handler
// to make $e get through the __toString() barrier.

This is a hack, but that's what the Debug component is about: leverage
several hacks and ship them as a set of useful experience-enhancers to devs.

In short, I'm all for deprecating $errcontext, and looking at the ongoing
vote it'll be accepted soon.

BUT, it would great to fix the inability of __toString to throw in 7.2 also.

Regards,
Nicolas

7 years ago by Stanislav Malyshev — view source

unread

Hi!

BUT, it would great to fix the inability of __toString to throw in 7.2 also.

That might be a bit harder to do. __toString does not throw because it's
used in many contexts inside the engine where you can't just drop what
you're doing and start processing the exception - like in the middle of
function accepting parameters, or in the middle of calculating the
expression, in the middle of executing a function call, etc. I'm not
saying it's impossible to do, but it would require adding a lot of very
carefully written code so that interrupting whatever the engine was
doing is safe, and even then not clear what to do with extensions which
won't have this code.

Stas Malyshev
smalyshev@gmail.com

[RFC] Deprecations for PHP 7.2

I am fine with deprecation, but this may be more wide spread than one might assume.

I am fine with deprecation, but this may be more wide spread than one
might assume.