Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Deprecations for PHP 7.3

Posted by Nikita Popov 
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 08, 2018 11:30PM
On Fri, Jul 6, 2018 at 6:50 AM, Kalle Sommer Nielsen <[email protected]> wrote:

> Den tor. 5. jul. 2018 kl. 22.51 skrev Kalle Sommer Nielsen <[email protected]
> >:
> >
> > Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov <[email protected]
> >:
> > > Sounds reasonable to me. My only question would be when we would start
> emitting the deprecation notice. I'm not a fan of deprecating things in the
> same release as the alternative is introduced, so I would suggest to add
> the new alias in PHP 7.3 and perform the deprecation in PHP 7.4.
> >
> > I agree here, I don't think a simple constant would hurt too much to
> > add outside the scope of this RFC so I will go ahead and do soonish
> > that if no one else objects. Then we can move the section to the 7.4
> > Deprecation WIP RFC.
>
> I wrote a quick patch[1] for this (look away from the deprecation
> warning), which basically adds a new alias 'add_slashes', this seemed
> like the easiest way to go about it. While looking into ext/filter it
> seems there are no implementations for INPUT_SESSION and
> INPUT_REQUEST. I doubt there is any intention to implement these so
> they could be potentials for adding a deprecation for (or simply
> removal as they just yield an E_WARNING when used anyway)[2].
>
>
> [1] https://gist.github.com/KalleZ/cce52f230d599501373b15729ec85bfc
> [2] https://git.php.net/?p=php-src.git;a=blob;f=ext/filter/filter.c;h=
> 56c93199f0bf4f713eeb81c0dfddb910b02b9618;hb=HEAD#l547
>

I assume that we're going forward with the addition of the alias, so I
moved the FILTER_SANITIZE_MAGIC_QUOTES deprecation from the PHP 7.3 to the
PHP 7.4 deprecations RFC.

I'll start the vote on this RFC (and the case-insensitive constants RFC)
tomorrow, with a duration of one week. I was holding off on these votes
because earlier comments in the typed references RFC thread made it appear
like a change to the release schedule was imminent, but as the RMs haven't
made a final decision yet and I can't hold off these votes further, I'll
have to keep them within the current schedule

Nikita
Christoph M. Becker
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 08, 2018 11:50PM
On 08.07.2018 at 23:18, Nikita Popov wrote:

> I'll start the vote on this RFC (and the case-insensitive constants RFC)
> tomorrow, with a duration of one week. I was holding off on these votes
> because earlier comments in the typed references RFC thread made it appear
> like a change to the release schedule was imminent, but as the RMs haven't
> made a final decision yet and I can't hold off these votes further, I'll
> have to keep them within the current schedule

Sorry, that there has not been any decision yet. However, Sara
suggested that this decision is not solely up to the RMs[1], and I
wouldn't know how to decide it then[2], since there has been at least
one objection[3].

[1] <https://externals.io/message/102333#102613>;
[2] <https://externals.io/message/102333#102648>;
[3] <https://externals.io/message/102333#102640>;

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 09, 2018 04:10AM
Den søn. 8. jul. 2018 kl. 23.18 skrev Nikita Popov <[email protected]>:
> I assume that we're going forward with the addition of the alias, so I moved the FILTER_SANITIZE_MAGIC_QUOTES deprecation from the PHP 7.3 to the PHP 7.4 deprecations RFC.

I implemented the 'add_slashes' filter to master so we should all be
good at that department. I will take care of updating the portion of
the 7.4 RFC to mention this new addition.



--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 09, 2018 04:50AM
Den søn. 8. jul. 2018 kl. 23.42 skrev Christoph M. Becker <[email protected]>:
> Sorry, that there has not been any decision yet. However, Sara
> suggested that this decision is not solely up to the RMs[1], and I
> wouldn't know how to decide it then[2], since there has been at least
> one objection[3].
>
> [1] <https://externals.io/message/102333#102613>;
> [2] <https://externals.io/message/102333#102648>;
> [3] <https://externals.io/message/102333#102640>;

I have a few concerns that if we push the GA date it will be too close
to christmas and would rather see the Typed Properties RFC as apart of
the next series of PHP personally. On the bright side, it does allow
us more time for a potential PHP8.


--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 09, 2018 04:50PM
On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker <[email protected]> wrote:
> Sorry, that there has not been any decision yet. However, Sara
> suggested that this decision is not solely up to the RMs[1], and I
> wouldn't know how to decide it then[2], since there has been at least
> one objection[3].
>
To clarify, it's ultimately an RM decision, but it should be guided by
the larger [email protected] group.

The way I read Zeev's objection is that it's primarily against TP, and
not against pushing out the FF per se. I would recommend (in a
non-RM, unofficial capacity) pushing out the FF (not necessarily GA,
but we can make that decision later). If these last minute things
pass, they go in. If they fail, then all we've done is burned a
month.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 09, 2018 06:50PM
On 09.07.2018 at 16:40, Sara Golemon wrote:

> On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker <[email protected]> wrote:
>
>> Sorry, that there has not been any decision yet. However, Sara
>> suggested that this decision is not solely up to the RMs[1], and I
>> wouldn't know how to decide it then[2], since there has been at least
>> one objection[3].
>
> To clarify, it's ultimately an RM decision, but it should be guided by
> the larger [email protected] group.
>
> The way I read Zeev's objection is that it's primarily against TP, and
> not against pushing out the FF per se. I would recommend (in a
> non-RM, unofficial capacity) pushing out the FF (not necessarily GA,
> but we can make that decision later). If these last minute things
> pass, they go in. If they fail, then all we've done is burned a
> month.

Perhaps we would not even “burn” a month, considering that several
extensions are still incompatible with PHP 7.3[1].

Anyway, I'd like to hear Stas' opinion on this matter.

[1]
https://blog.remirepo.net/post/2018/07/02/PHP-extensions-status-with-upcoming-PHP-7.3

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
David Zuelke
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 09, 2018 09:30PM
On Tue, Jun 26, 2018 at 6:32 PM Kalle Sommer Nielsen <[email protected]> wrote:
>
> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <[email protected]>:
> > If you have a minor deprecation in mind, but were too lazy to write an RFC
> > for it, please write me a mail until tomorrow, so that it might be included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> As suggested in the past, I would like to add the following to this
> list (if its not too late):
>
> - The (real) type-cast and its function, is_real(). There doesn't
> seem to be any support for reals in settype() anyway (side note: in
> the implementation of settype() it claims "double" is deprecated)
> - Function variants that already exists as constants, php_sapi_name()
> > PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc

Keep in mind you can do phpversion("extensionname"), so that function
at least can't be removed, as the constant doesn't provide the same
functionality.

David

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 09, 2018 09:30PM
Den man. 9. jul. 2018 kl. 21.22 skrev David Zuelke <[email protected]>:
> Keep in mind you can do phpversion("extensionname"), so that function
> at least can't be removed, as the constant doesn't provide the same
> functionality.

Sure, but almost all of the core extensions return PHP_VERSION anyway
(thanks to Peter K.) and the information is still available with echo
(new ReflectionExtension('extensionname'))->getVersion(); and I doubt
there is a massive usage so the impact is very minimal and therefore I
believe its a fair compromise.


--
regards,

Kalle Sommer Nielsen
kalle@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
RE: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 08:20AM
> -----Original Message-----
> From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
> Golemon
> Sent: Monday, July 9, 2018 5:41 PM
> To: Christoph M. Becker <[email protected]>
> Cc: Nikita Popov <[email protected]>; Kalle Sommer Nielsen
> <[email protected]>; Internals <[email protected]>
> Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
>
> On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker <[email protected]>
> wrote:
> > Sorry, that there has not been any decision yet. However, Sara
> > suggested that this decision is not solely up to the RMs[1], and I
> > wouldn't know how to decide it then[2], since there has been at least
> > one objection[3].
> >
> To clarify, it's ultimately an RM decision, but it should be guided by the larger
> [email protected] group.
>
> The way I read Zeev's objection is that it's primarily against TP, and not against
> pushing out the FF per se. I would recommend (in a non-RM, unofficial capacity)
> pushing out the FF (not necessarily GA, but we can make that decision later). If
> these last minute things pass, they go in. If they fail, then all we've done is
> burned a month.

It's a bit of both really.

I hope that with all things considered (the little time we have left, the little concrete discussion that happened so far as a result, the inconsistency of allowing such a vote to push out feature freeze, the scope of this feature being a lot more suitable for a major release, and our inability to fix/improve other related elements at the same time) - Nikita will propose this for 8.0 instead of 7.x.

Zeev



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 09:40AM
On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski <[email protected]> wrote:

>
>
> > -----Original Message-----
> > From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
> > Golemon
> > Sent: Monday, July 9, 2018 5:41 PM
> > To: Christoph M. Becker <[email protected]>
> > Cc: Nikita Popov <[email protected]>; Kalle Sommer Nielsen
> > <[email protected]>; Internals <[email protected]>
> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
> >
> > On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker <[email protected]>
> > wrote:
> > > Sorry, that there has not been any decision yet. However, Sara
> > > suggested that this decision is not solely up to the RMs[1], and I
> > > wouldn't know how to decide it then[2], since there has been at least
> > > one objection[3].
> > >
> > To clarify, it's ultimately an RM decision, but it should be guided by
> the larger
> > [email protected] group.
> >
> > The way I read Zeev's objection is that it's primarily against TP, and
> not against
> > pushing out the FF per se. I would recommend (in a non-RM, unofficial
> capacity)
> > pushing out the FF (not necessarily GA, but we can make that decision
> later). If
> > these last minute things pass, they go in. If they fail, then all we've
> done is
> > burned a month.
>
> It's a bit of both really.
>
> I hope that with all things considered (the little time we have left, the
> little concrete discussion that happened so far as a result, the
> inconsistency of allowing such a vote to push out feature freeze, the scope
> of this feature being a lot more suitable for a major release, and our
> inability to fix/improve other related elements at the same time) - Nikita
> will propose this for 8.0 instead of 7.x.
>

To make sure there are no unreasonable expectations involved in this
decision: If this feature will not go into PHP 7.3, then it will in all
likelihood go into PHP 7.4 instead. I think I can safely say not just on
behalf on Bob and myself, but also on behalf of the wider PHP community,
that we are not willing to sit on this feature for 2.5~3 years until a
hypothetical PHP 8, even though it is essentially ready *now*. Of course,
this is not my decision to make, but as Sara put it, that's the writing on
the wall. By deciding not to include this in PHP 7.3, we are essentially
making an implicit decision that PHP 7.4 is going to be a relatively
ordinary feature release rather than a deprecation-only one. (Which is fine
by me really, I don't like the idea of a release that's all stick and no
carrot.)

Finally, given the current situation where we have a whopping five (!!)
RFCs with votes ending the day before feature freeze, I'd say postponing
the schedule is a good idea even without any consideration to typed
properties. Just landing something like the comparison overloading RFC on
the day of feature freeze is not going to be pretty. We are quite obviously
rushing things right now, and I don't think keeping to some otherwise
arbitrary date is worth that.

Regards,
Nikita
Zeev Suraski
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 10:10AM
On Tue, Jul 10, 2018 at 10:36 AM Nikita Popov <[email protected]> wrote:

> On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski <[email protected]> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
>> > Golemon
>> > Sent: Monday, July 9, 2018 5:41 PM
>> > To: Christoph M. Becker <[email protected]>
>> > Cc: Nikita Popov <[email protected]>; Kalle Sommer Nielsen
>> > <[email protected]>; Internals <[email protected]>
>> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
>> >
>> > On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker <[email protected]>
>> > wrote:
>> > > Sorry, that there has not been any decision yet. However, Sara
>> > > suggested that this decision is not solely up to the RMs[1], and I
>> > > wouldn't know how to decide it then[2], since there has been at least
>> > > one objection[3].
>> > >
>> > To clarify, it's ultimately an RM decision, but it should be guided by
>> the larger
>> > [email protected] group.
>> >
>> > The way I read Zeev's objection is that it's primarily against TP, and
>> not against
>> > pushing out the FF per se. I would recommend (in a non-RM, unofficial
>> capacity)
>> > pushing out the FF (not necessarily GA, but we can make that decision
>> later). If
>> > these last minute things pass, they go in. If they fail, then all
>> we've done is
>> > burned a month.
>>
>> It's a bit of both really.
>>
>> I hope that with all things considered (the little time we have left, the
>> little concrete discussion that happened so far as a result, the
>> inconsistency of allowing such a vote to push out feature freeze, the scope
>> of this feature being a lot more suitable for a major release, and our
>> inability to fix/improve other related elements at the same time) - Nikita
>> will propose this for 8.0 instead of 7.x.
>>
>
> To make sure there are no unreasonable expectations involved in this
> decision: If this feature will not go into PHP 7.3, then it will in all
> likelihood go into PHP 7.4 instead. I think I can safely say not just on
> behalf on Bob and myself, but also on behalf of the wider PHP community,
> that we are not willing to sit on this feature for 2.5~3 years until a
> hypothetical PHP 8, even though it is essentially ready *now*. Of course,
> this is not my decision to make, but as Sara put it, that's the writing on
> the wall. By deciding not to include this in PHP 7.3, we are essentially
> making an implicit decision that PHP 7.4 is going to be a relatively
> ordinary feature release rather than a deprecation-only one. (Which is fine
> by me really, I don't like the idea of a release that's all stick and no
> carrot.)
>

Thanks for choosing not to push it for 7.3. At the same time - I think the
push for inclusion in 7.4 will be regrettable. Other parts of what I'd
like to see in PHP 8 is, in fact, ready and can theoretically become a part
of PHP 7.4 (even JIT, potentially). The reason we're doing it is twofold -
one, that's the expectation around major releases - that they will come
with major new features; And two, perhaps more importantly - is that big
features sweeten the deal associated with migrating to a new major
versions, with the incompatibilities introduced and the code audits
required. I obviously know it's extremely difficult to sit on new working
code for prolonged periods of time - but it can very much be the right
thing to do. We did exactly that with the phpng codebase (which introduced
virtually zero incompatibilities, and could in theory be included in PHP
5.7), and we're likely going to do that again with JIT and FFI. Either
way, I'll state my case when the discussion becomes relevant again.

In the PHP 8 RFC that I'm hoping to begin drafting in the near future, my
goal is to present 7.4 as a 'deprecation mostly' version, which while it
won't be forbidden to include new functionality in it, it will be
discouraged (with probably no 'teeth' to this discouragement, i.e. a
successful vote would still land a new feature into 7.4).

Zeev
Zeev Suraski
RE: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 12:20PM
Upon re-reading what you wrote, I realized that I in fact misread what you wrote and you didn't make a decision on whether to push for including it in 7.3 or not (I guess I was reading what I was expecting/hoping to read and not what was actually there...). Sorry for that, I did not mean to force words into your mouth.

Zeev

-----Original Message-----
From: Zeev Suraski [mailto:[email protected]]
Sent: Tuesday, July 10, 2018 11:05 AM
To: Nikita Popov <[email protected]>
Cc: Sara Golemon <[email protected]>; Christoph M. Becker <[email protected]>; Kalle Sommer Nielsen <[email protected]>; Internals <[email protected]>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

Thanks for choosing not to push it for 7.3.
Christoph M. Becker
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 12:40PM
On 10.07.2018 at 09:36, Nikita Popov wrote:

> To make sure there are no unreasonable expectations involved in this
> decision: If this feature will not go into PHP 7.3, then it will in all
> likelihood go into PHP 7.4 instead. I think I can safely say not just on
> behalf on Bob and myself, but also on behalf of the wider PHP community,
> that we are not willing to sit on this feature for 2.5~3 years until a
> hypothetical PHP 8, even though it is essentially ready *now*. Of course,
> this is not my decision to make, but as Sara put it, that's the writing on
> the wall. By deciding not to include this in PHP 7.3, we are essentially
> making an implicit decision that PHP 7.4 is going to be a relatively
> ordinary feature release rather than a deprecation-only one. (Which is fine
> by me really, I don't like the idea of a release that's all stick and no
> carrot.)
>
> Finally, given the current situation where we have a whopping five (!!)
> RFCs with votes ending the day before feature freeze, I'd say postponing
> the schedule is a good idea even without any consideration to typed
> properties. Just landing something like the comparison overloading RFC on
> the day of feature freeze is not going to be pretty. We are quite obviously
> rushing things right now, and I don't think keeping to some otherwise
> arbitrary date is worth that.

Good point! Thus, I suggest to put in *one* additional alpha (i.e.
postponing feature freeze by two weeks to 2018-07-31) in any case, have
the vote on “Typed Properties” starting soon with explicit options which
version these should be merged into, and if there will be an option to
target PHP 7.3, *and* the voters decide it should go into PHP 7.3, to
insert yet an additional alpha5.

Anyhow, I strongly suggest to amend our voting and release rules to
avoid such situations in the future. Ending any vote one day or a few
days before feature freeze should simply not be allowed (unless the RFC
targets another version). And there should be clear rules which
circumstances warrant or allow to postpone feature freeze, and who's
decision that is.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 02:50PM
On Tue, Jul 10, 2018 at 12:35 PM, Christoph M. Becker <[email protected]>
wrote:

> On 10.07.2018 at 09:36, Nikita Popov wrote:
>
> > To make sure there are no unreasonable expectations involved in this
> > decision: If this feature will not go into PHP 7.3, then it will in all
> > likelihood go into PHP 7.4 instead. I think I can safely say not just on
> > behalf on Bob and myself, but also on behalf of the wider PHP community,
> > that we are not willing to sit on this feature for 2.5~3 years until a
> > hypothetical PHP 8, even though it is essentially ready *now*. Of course,
> > this is not my decision to make, but as Sara put it, that's the writing
> on
> > the wall. By deciding not to include this in PHP 7.3, we are essentially
> > making an implicit decision that PHP 7.4 is going to be a relatively
> > ordinary feature release rather than a deprecation-only one. (Which is
> fine
> > by me really, I don't like the idea of a release that's all stick and no
> > carrot.)
> >
> > Finally, given the current situation where we have a whopping five (!!)
> > RFCs with votes ending the day before feature freeze, I'd say postponing
> > the schedule is a good idea even without any consideration to typed
> > properties. Just landing something like the comparison overloading RFC on
> > the day of feature freeze is not going to be pretty. We are quite
> obviously
> > rushing things right now, and I don't think keeping to some otherwise
> > arbitrary date is worth that.
>
> Good point! Thus, I suggest to put in *one* additional alpha (i.e.
> postponing feature freeze by two weeks to 2018-07-31) in any case, have
> the vote on “Typed Properties” starting soon with explicit options which
> version these should be merged into, and if there will be an option to
> target PHP 7.3, *and* the voters decide it should go into PHP 7.3, to
> insert yet an additional alpha5.
>

That sounds like a very reasonable approach to me.

Anyhow, I strongly suggest to amend our voting and release rules to
> avoid such situations in the future. Ending any vote one day or a few
> days before feature freeze should simply not be allowed (unless the RFC
> targets another version). And there should be clear rules which
> circumstances warrant or allow to postpone feature freeze, and who's
> decision that is.
>

Ugh yes. A hard rule that no new RFCs targeting the branch can be submitted
4 or 5 weeks before the feature freeze would be reasonable and would avoid
this mess in the future. Especially if could get an announcement about the
approaching "RFC freeze" a month or so in advance.

Nikita
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 10, 2018 10:00PM
Hi!

> the wall. By deciding not to include this in PHP 7.3, we are essentially
> making an implicit decision that PHP 7.4 is going to be a relatively
> ordinary feature release rather than a deprecation-only one. (Which is fine
> by me really, I don't like the idea of a release that's all stick and no
> carrot.)

I am completely fine with that too. I don't see why 7.4 should be
deprecation-only if we have new pending features that are ready by 7.4.

> Finally, given the current situation where we have a whopping five (!!)
> RFCs with votes ending the day before feature freeze, I'd say postponing
> the schedule is a good idea even without any consideration to typed
> properties. Just landing something like the comparison overloading RFC on
> the day of feature freeze is not going to be pretty. We are quite obviously

I would be also against that, but the current voting pattern suggest the
vote may make the question moot anyway. That said, typed properties are
IMO much larger than comparison overloading RFC, which is still a bit
niche. I would be most happy to have both in 7.4 if they pass, but I
don't think it would be a major problem if comparison overloading one is
passed and we delay 7.3 a bit to accommodate it. But for typed
properties I think we should just target 7.4 and not even consider
rushing with it.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login