Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain pmmaga.net designates 149.210.149.69 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 25 Nov 2016 13:05:06 +0100
To: PHP Internals List <internals@lists.php.net>
In-Reply-To: <cdd4edeaf066e73ca2ebdede5d5c535b@pmmaga.net>
References: <cdd4edeaf066e73ca2ebdede5d5c535b@pmmaga.net>
Message-ID: <0d68926cf887b7097f56a613148210da@pmmaga.net>
User-Agent: Webmail
Subject: Re: Binary string forward compatibility removal
From: mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)

On 2016-11-06 20:22, Pedro Magalhães wrote:
> Hi internals,
> 
> I've created a PR (https://github.com/php/php-src/pull/2187) aiming at
> the removal of the binary string forward compatibility.
> 
> Reproducing the description of the PR:
> ----
> In version 5.2.1, the b prefix and the (binary) cast were introduced
> for forward compatibility with the PHP6 project. As it is known, that
> project never came to be. However, these are still accepted by the
> language scanner although ignored from then on.
> 
> This PR aims at removing those as they are naturally confusing given
> that they are simply ignored or, in the case of the cast, the same as
> casting to string.
> 
> However, I've separated this PR in 2 commits because the removal of
> the (binary) cast will bring a more serious BC break issue: On the
> PHAR extension, the current default stub for PHAR's makes use of the
> binary cast. I've removed it from the default stub and fixed the tests
> that made use of it but this means that the old PHARs that make use of
> this default stub will be broken.
> 
> What seemed to be a simple task actually turned out to be far more
> complex given the number of tests that were written with this forward
> compatibility in mind.
> 
> I would be happy to transform this into an RFC if you think it would
> be appropriate.
> ----
> 
> Any feedback would be greatly appreciated.
> 
> Best regards,
> Pedro Magalhães

Hello, internals!

Based on the feedback here and on GitHub, this change should go through
a deprecation phase and there should be an RFC about it.

This deprecation is also covered on Nikita's deprecations RFC but we
agreed to take this on separately as it has the BC break issue for old
PHAR's.

Given that, I would like to request for rfc karma on the wiki for my
user: "pmmaga"

Thank you in advance,
Pedro Magalhães