Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84308
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.213.43 cause and error)
MIME-Version: 1.0
In-Reply-To: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
References: <885a29db28bc96b2d3cd2ac96907e39f@mail.gmail.com>
Date: Thu, 5 Mar 2015 00:16:01 +0000
Message-ID: <CA+kxMuQwa1P9ppSDc9x_PXhV3tgjAwmhF0FGVLFUX2tN_PXBbg@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
From: danack@basereality.com (Dan Ackroyd)

On 2 March 2015 at 14:24, Zeev Suraski <zeev@zend.com> wrote:
> 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;
>
> Should we not go through this deprecation cycle, even if may feel anxious
> to get rid of this behavior?

I don't think it's required.

The purpose of deprecation notices is to allow people to detect issues
in their code that is currently working as they want, and without
giving any warning messages. This allows them to estimate how much
effort it would be to upgrade to a newer version of PHP, one in which
the behaviour is no longer allowed, without actually having to
refactor all the code to find out.

In this case, the code already produces a notice that says the
behaviour is not completely ok, so people are able to detect where
array to string conversion is happening.

Having an intermediate step of E_DEPRECATED notice would not affect
the amount of code that they would need to change nor will it make it
significantly easier to detect places in their code where this
behaviour is occurring.

cheers
Dan