Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85223
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <077401d06268$2b597c30$820c7490$@php.net>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
	<077401d06268$2b597c30$820c7490$@php.net>
Date: Thu, 19 Mar 2015 17:40:07 +0000
Message-ID: <CA+kxMuRG7RV74uD=pJxB2M3LS9Ty1xB-+TN_ddMpYg4xgtjpwA@mail.gmail.com>
To: francois@php.net
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: danack@basereality.com (Dan Ackroyd)

On 19 March 2015 at 17:14, Fran=C3=A7ois Laupretre <francois@php.net> wrote=
:

> As you may have noticed if you had a look at the RFC or twitter, I have d=
ecided to follow people's suggestion.
> Please note that the switch from E_DEPRECATED to fatal error won't requir=
e any new RFC/discussion/vote
> as the  fatal error is considered as approved. I just introduce an E_DEPR=
ECATED phase for 7.0.

What. The. Fuck.

You edited the RFC after the voting had closed? You are not allowed to
edit an RFC after the voting has occurred.

I don't think we have any rules in place to deal with this; I don't
think anyone anticipated that anyone would actually try to do this. We
obviously need an explicit rule for this, but that can wait until 7.0
is closer to shipping, and we can contemplate RFC rules at leisure.

For now, please revert the changes your made to the RFC after it had
been closed. And whoever has the power to remove karma, please take
the power to edit RFCs away from Francois once that has been done.

> Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fat=
al error in 7.1 or 7.2.

You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.

E_DEPRECATED is not a magic bullet - that makes all BC problems go
away. The reason why we voted on it for 7.0 is that it is a major
break, but one that is acceptable to be done at a major version. It
would not be acceptable to change the behaviour in a minor version.

cheers
Dan