Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83626
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <408f8a8532601425b1c501f333fa6135@mail.gmail.com>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
	<CAEPJduk3VgWYgpuJ4G0JvUXYaMoO7430Q0k7v5ifwWF_dzh9rA@mail.gmail.com>
	<9aec85c81b49009c6238ff6d8be27cd4@mail.gmail.com>
	<CAEPJdukoBG3M1q3UqJ9LW-GBqhVB7-ybkdJqiGENN2w10XqEhw@mail.gmail.com>
	<f881d1e1bb6026b96498cfd787d3fd0a@mail.gmail.com>
	<CAEPJdumFJup3mKsaYxi11O0f6L3BAvOUa=Z9tTKy8B01tvu8PQ@mail.gmail.com>
	<2dcfd9f4a3f0f9bbf2a13f679359e6ea@mail.gmail.com>
	<CAEPJdunt2GxC0tmwmkegAOfeuZ992XLaRB--Y6W9AE1Z4Lg7KA@mail.gmail.com>
	<6844321d7134506b1061c5f18a275069@mail.gmail.com>
	<CAAyV7nEuWr4hAxFWZCB+CKsoQoisyitfW5Y+H7s5=wVid3_9rQ@mail.gmail.com>
	<408f8a8532601425b1c501f333fa6135@mail.gmail.com>
Date: Mon, 23 Feb 2015 18:53:55 -0800
Message-ID: <CAEZPtU48y-aeRXLnK5GM=FdnzzRVd1syvoorYs+AYy-59wsJBA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Feb 23, 2015 at 2:53 PM, Zeev Suraski <zeev@zend.com> wrote:

> Thanks for testing, but it's a bit premature to jump to conclusions.
>
> First, disabling phar is in the patch instructions at
> github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be
> fixed.  We'll address it.
>
> Secondly, as was obvious both from Francois' email and mine, this is just an
> initial patch, and yes, we know it presently fails 8% of the test cases (as
> I stated a few hours ago in an email to Benjamin).  I still think it's not a
> bad start at all;  It would be a pretty bad ending, but I think we can tweak
> the rules to get a lot less breakage.  If you're up for it, you can
> experiment with the many the 12 configuration switches that govern this
> patch - but even that is a bit premature.  Let people who actually want this
> RFC to pass try and tweak the patch first :)

I understand it is a initial patch. However I totally fail to see how
changing the casting rules by default is doing us and our users
anything good.

Yes, they are inconsistent, nobody can remember or even know all of
them or edge cases. But after a decade or more, most of them (rare
"magic" edge cases are partially covered already) are part of what a
huge amount of codes rely on. As Benjamin pointed out, most of these
codes are not tested. And for the parts being tested, I can say that
it is nearly impossible to extrapolate the impact of such change in
user land. It is not a lack of desire to do so but the very large and
difficult surface we have to cover. I will be against any change in
this area not related to extreme edge cases, if done by default
without any possibility to disable the new casting behaviors. I
consider as a expected disaster in order of magnitude bigger than what
we see in python 2>3.

> Thirdly, as I shared earlier, the RFC was updated to go for E_DEPRECATED in
> PHP 7, which means there would be zero breakage in PHP 7, and ample time for
> people to migrate whatever issues this would introduce to their code until
> PHP 8.  All functionality changes will go through the E_DEPRECATED cycle,
> exactly like the stuff that got removed in PHP 7.

Well, E_DEPRECATED as it is now has no meaning. But why not.

That being said, again, I do not see how changing casting rules won't
introduce BC breaks. Please enlighten me.

> Last, we don't yet have an answer to your question about the billions of
> lines of code out there.  But as I told to Benjamin, we have every intention
> to try the patch out on some real world apps and see how it performs.

Patch applications to test something that does not break BC? I
understand the need of testing a new feature and we do similar things
for strict typing interacting with legacy code, but one must do test
case is legacy codes remaining untouched to actually see the impact,
with or without new addition of modules or codes relying on  a new
mode.

> Let me assure you that if we find that there are hundreds of issues trying
> to get common apps to work, after we tweak the rules - I'll either retract
> the RFC or the very least rethink the internal functions part of it.

The common apps are a very but loud part of the PHP codes out there. I
worry about these parts more than about Wordpress, for example.