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

2016-11-18 Thread Nikita Popov
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 RF

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-18 Thread Kalle Sommer Nielsen
Hi Nikita 2016-11-18 15:55 GMT+01:00 Nikita Popov : > 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 > perform

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-18 Thread Christoph M. Becker
On 18.11.2016 at 20:01, Kalle Sommer Nielsen wrote: > 2016-11-18 15:55 GMT+01:00 Nikita Popov : > >> 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 la

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-18 Thread Yasuo Ohgaki
Hi all, On Sat, Nov 19, 2016 at 4:01 AM, Kalle Sommer Nielsen wrote: > 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 t

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-18 Thread Kalle Sommer Nielsen
2016-11-19 1:05 GMT+01:00 Yasuo Ohgaki : > Hi all, > > On Sat, Nov 19, 2016 at 4:01 AM, Kalle Sommer Nielsen wrote: >> auto_prepend/auto_append_file directives > > auto_prepend/append_file is handy to check application > performance/statistical information such as memory usage while > development

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Rowan Collins
On 18/11/2016 14:55, Nikita Popov 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://w

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Kalle Sommer Nielsen
Hi Rowan 2016-11-19 18:23 GMT+01:00 Rowan Collins : > 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? > > Previo

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Marco Pivetta
On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen 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'

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Christoph M. Becker
On 19.11.2016 at 18:56, Marco Pivetta wrote: > On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen 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 t

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Christoph M. Becker
On 19.11.2016 at 18:23, Rowan Collins wrote: > 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

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Kalle Sommer Nielsen
Hi Marco 2016-11-19 18:56 GMT+01:00 Marco Pivetta : > 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 Se

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Rowan Collins
On 19/11/2016 17:56, Marco Pivetta wrote: On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen > 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 sa

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Kalle Sommer Nielsen
Hi Christoph 2016-11-19 19:23 GMT+01:00 Christoph M. Becker : > 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 f

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Christoph M. Becker
Hi Kalle! On 19.11.2016 at 19:35, Kalle Sommer Nielsen wrote: > 2016-11-19 19:23 GMT+01:00 Christoph M. Becker : > >> 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

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Kalle Sommer Nielsen
Hi Christoph 2016-11-19 19:56 GMT+01:00 Christoph M. Becker : > 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 > mon

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Rowan Collins
On 19/11/2016 18:35, Kalle Sommer Nielsen wrote: 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") r

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-19 Thread Kalle Sommer Nielsen
2016-11-19 22:56 GMT+01:00 Rowan Collins : > 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 s

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-20 Thread Rowan Collins
On 19/11/2016 23:05, Kalle Sommer Nielsen wrote: 2016-11-19 22:56 GMT+01:00 Rowan Collins : 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 mode

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-20 Thread Derick Rethans
On Fri, 18 Nov 2016, Nikita Popov 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. > >

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-20 Thread Daniel Morris
On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote: > __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. Upgra

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-20 Thread Rowan Collins
On 20/11/2016 22:50, Daniel Morris wrote: On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote: >__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_

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-20 Thread Alice Wonder
On 11/20/2016 02:32 PM, Rowan Collins wrote: 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 i

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-11-21 Thread Kalle Sommer Nielsen
Hi 2016-11-18 15:55 GMT+01:00 Nikita Popov : > 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. >

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-12-10 Thread Kalle Sommer Nielsen
Hi Nikita 2016-11-18 15:55 GMT+01:00 Nikita Popov : > 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 > perfor

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2016-12-10 Thread Maciej Sobaczewski
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 : 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 vot

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2017-01-24 Thread Nicolas Grekas
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/

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2

2017-01-26 Thread Stanislav Malyshev
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 o