Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84317
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAMUwpuQfDo=-i3F2GdqkBoWoCMmW9_qhjmjAQSeAX+5YvcpGBA@mail.gmail.com>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
 <CACwt+JdL3YUQWHP04HOHHeE1=B98d8wgKT2VquWRJrEzmTfTXg@mail.gmail.com> <CAMUwpuQfDo=-i3F2GdqkBoWoCMmW9_qhjmjAQSeAX+5YvcpGBA@mail.gmail.com>
Date: Thu, 5 Mar 2015 14:28:14 +0900
Message-ID: <CAGa2bXZ4SyxpbTosY2EawvDCr4OEmOETte-Wpdb35o7QjqUa7A@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Patrick ALLAERT <patrickallaert@php.net>, Zeev Suraski <zeev@zend.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135a5140407f5051083d89c
Subject: Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1135a5140407f5051083d89c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Tue, Mar 3, 2015 at 2:30 AM, Julien Pauli <jpauli@php.net> wrote:

> 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=A9=
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=E2=80=99s addressed in the RFC =E2=80=93 but I=E2=80=99m 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=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
> anxious
> > > to get rid of this behavior?
> > >
> >
> > I'm all for deprecating before it gets removed (especially since I vote=
d
> > "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 thi=
s
> doesn't mean 7.0 shouldn't deprecate anything IMO.
>

I had same idea, but I voted yes.

Conversion from array to string is a bug should be fixed anyway.
There may be code that checks invalid "Array" string, though.

I think changing E_NOTICE to E_DEPRECATED/E_STRICT is good idea.
E_DEPRECATED/E_STRICT then E_NOTICE/E_WARNING/E_ERROR
is better path. Users should be able to catch bugs with
E_DEPRECATED/E_STRICT
also.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1135a5140407f5051083d89c--