Re: Question/comment about the Array to String conversion RFC

From: Date: Mon, 02 Mar 2015 17:30:17 +0000
Subject: Re: Question/comment about the Array to String conversion RFC
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-84173@lists.php.net to get a copy of this message
On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT <patrickallaert@php.net> wrote: > Le lun. 2 mars 2015 à 15:24, Zeev Suraski <zeev@zend.com> a écrit : > > > All, > > > > > > > > https://wiki.php.net/rfc/array-to-string (which I voted > > yes to) deviates > > from our guidelines of deprecating features first, and removing them > > later; It’s addressed in the RFC – but I’m a bit worried that this opens > > the door to jumping from any sort of notice/warning into errors or > removed > > features without any deprecation phase. > > > > > > > > In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any > > proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through > > E_DEPRECATED. > > > > > > > > Should we not go through this deprecation cycle, even if may feel anxious > > to get rid of this behavior? > > > > I'm all for deprecating before it gets removed (especially since I voted > "no" to that). > > Same to me, I voted no because we're gonna break something which is not "that bad" and turn it to a clear breakage in one step. I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0 and remove in 7.1 or 7.2 or whatever. We chose not to have a 5.7 for deprecation purpose only (or not), but this doesn't mean 7.0 shouldn't deprecate anything IMO. Julien.Pauli

« previous php.internals (#84173) next »