Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <077401d06268$2b597c30$820c7490$@php.net>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
	<077401d06268$2b597c30$820c7490$@php.net>
Date: Fri, 20 Mar 2015 04:28:36 +1100
Message-ID: <CAEZPtU637+-ho97x4fTiu0JG7S-+ZYE67DzCePC7=vYy=R+awA@mail.gmail.com>
To: francois@php.net
Cc: PHP internals <internals@lists.php.net>, Zeev Suraski <zeev@zend.com>
Content-Type: multipart/alternative; boundary=001a113ffb46ad5aff0511a78729
Subject: RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: pierre.php@gmail.com (Pierre Joye)

--001a113ffb46ad5aff0511a78729
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mar 20, 2015 12:14 AM, "Fran=C3=A7ois Laupretre" <francois@php.net> wrot=
e:
>
> > De : Zeev Suraski [mailto:zeev@zend.com]
> >
> > 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
anxious
> > to get rid of this behavior?
>
> Sorry for the delay but I could not send emails during the last 3 weeks.
>
> As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion. Array to string conversion will
raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2.

Hmm.. Sorry but no. I really do not think we can do this, this will bring a
major BC in 7.1+ and we do not allow BC but in extreme cases.

> Please note that the switch from E_DEPRECATED to fatal error won't
require any new RFC/discussion/vote as the fatal error is considered as
approved. I just introduce an E_DEPRECATED phase for 7.0.

Well, if it is, do it in 7.0. But changing that all of a sudden and making
it fatal in 7.1+ is an extremely bad idea :)

> Regards
>
> Fran=C3=A7ois
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--001a113ffb46ad5aff0511a78729--