Re: Question/comment about the Array to String conversion RFC
| From: | Julien Pauli | 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