Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85226
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.181 as permitted sender)
Message-ID: <550B0D08.3010607@gmail.com>
Date: Thu, 19 Mar 2015 17:53:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>	<077401d06268$2b597c30$820c7490$@php.net> <CA+kxMuRG7RV74uD=pJxB2M3LS9Ty1xB-+TN_ddMpYg4xgtjpwA@mail.gmail.com>
In-Reply-To: <CA+kxMuRG7RV74uD=pJxB2M3LS9Ty1xB-+TN_ddMpYg4xgtjpwA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Question/comment about the Array to String conversion
 RFC
From: rowan.collins@gmail.com (Rowan Collins)

Dan Ackroyd wrote on 19/03/2015 17:40:
> On 19 March 2015 at 17:14, François Laupretre <francois@php.net> wrote:
>
>> As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion.
>> 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.
> What. The. Fuck.

I agree with the substance of what you wrote, but would like to appeal 
for some civility and Assumption of Good Faith.

When you find yourself typing the word "fuck" on a public mailing list, 
you should pause, make a cup of tea, and redraft the e-mail.


> You edited the RFC after the voting had closed? You are not allowed to
> edit an RFC after the voting has occurred.

Yes, this was not a good idea. The RFC as accepted was for a fatal 
error; a change to E_DEPRECATED would require a new RFC, or at least a 
supplementary vote.


> 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.

Let's keep this in perspective - no permanent harm has been done, anyone 
can revert the page, and Francois can learn from the mistake. These two 
paragraphs can be boiled down to "Can you or someone revert it please, 
to reflect the text as accepted."


>> Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2.
> You are being dumb here as well.

This sentence is simply unnecessary.


> 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.

This point is valid.

Regards,
-- 
Rowan Collins
[IMSoP]