Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84173
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CACwt+JdL3YUQWHP04HOHHeE1=B98d8wgKT2VquWRJrEzmTfTXg@mail.gmail.com>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com> <CACwt+JdL3YUQWHP04HOHHeE1=B98d8wgKT2VquWRJrEzmTfTXg@mail.gmail.com>
Date: Mon, 2 Mar 2015 18:30:17 +0100
Message-ID: <CAMUwpuQfDo=-i3F2GdqkBoWoCMmW9_qhjmjAQSeAX+5YvcpGBA@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae9cc97c8c69b5a0510519401
Subject: Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: jpauli@php.net (Julien Pauli)

--14dae9cc97c8c69b5a0510519401
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT <patrickallaert@php.net>
wrote:

> Le lun. 2 mars 2015 =C3=A0 15:24, Zeev Suraski <zeev@zend.com> a =C3=A9cr=
it :
>
> > All,
> >
> >
> >
> > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviate=
s
> > from our guidelines of deprecating features first, and removing them
> > later;  It=E2=80=99s addressed in the RFC =E2=80=93 but I=E2=80=99m a b=
it 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=E2=80=99s RFC for removing E_STRICT =E2=80=93 =
there aren=E2=80=99t any
> > proposed =E2=80=98jumps=E2=80=99 to E_RECOVERABLE_ERROR that don=E2=80=
=99t first go through
> > E_DEPRECATED.
> >
> >
> >
> > Should we not go through this deprecation cycle, even if may feel anxio=
us
> > 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

--14dae9cc97c8c69b5a0510519401--