Hi Zeev, On 19 March 2015 at 17:49, Zeev Suraski <z...@zend.com> wrote: > Technically, we're not allowed to move from from a working feature into a > removed one without a deprecation phase.
Please can you point me to where this is written down? Please also show me where it says that this rule cannot be over-ridden by an RFC, which is our path of changing rules. The point of deprecating things is to smooth the path of fixing issues. It allows people to detect in their codebase places where there is code that is currently working fine without error, that is going to break in a future version of PHP. Any array to string conversion is already detectable as it emits a 'notice'. It does not need an intermediate step of changing the notice to being a deprecation warning; that provides no benefit to users. Rowan wrote: > you should pause, make a cup of tea, and redraft the e-mail. That was the redrafted version. The edits to the RFC were made two weeks ago. In Francois' defence he himself alerted the list to the changes. But the unapproved editing also meant that if there was someone else who was concerned about the BC break, they might not have raised an RFC to revert the RFC, before the cut off time for RFCs. This is one of the reasons why someone editing the text of a passed RFC is utterly unacceptable. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
