Anthony, 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 :) 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. 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. 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. Zeev > -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Tuesday, February 24, 2015 12:25 AM > To: Zeev Suraski > Cc: Benjamin Eberlei; PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > Zeev, > > > Secondly, for some reason you appear very opinionated that this will > > result in huge breakage, even though we don't yet have any evidence to > > suggest it'd be the case, at least not yet. > > So I tried to compile the patch to get a real-world idea of the breaks. > > The first thing, PHP's own phar generator included in the make file fails > due > to the new restricted hints (based on the patch provided). > (I had to rebuild with --disable-phar to get it to build). > > Let me make that perfectly clear: under these changes you cannot do a > default compile of PHP due to BC breaks. > > Let's take a look at the numbers. I just ran a > ./configure --enable-mbstring -- > disable-phar --enable-debug, and got the following test results: > > Number of tests : 13653 9008 > Tests skipped : 4645 ( 34.0%) -------- > Tests warned : 0 ( 0.0%) ( 0.0%) > Tests failed : 697 ( 5.1%) ( 7.7%) > Expected fail : 32 ( 0.2%) ( 0.4%) > Tests passed : 8279 ( 60.6%) ( 91.9%) > --------------------------------------------------------------------- > Time taken : 954 seconds > > 7.7% of the internal test suite is extremely significant. That's just > short of 700 > tests on a reasonably default install. > > So I recompiled with a bunch more extensions: > > Number of tests : 13716 10343 > Tests failed : 811 ( 5.9%) ( 7.8%) > > And that's for PHP's suite. What about for the hundreds of millions of > lines of > code of untested apps out there? > > I tried running Symfony 2's test suite, but couldn't. Because: > > $ ../php-src/sapi/cli/php vendor/bin/phpunit > > Warning: debug_backtrace() expects parameter 1 to be integer, boolean > given in Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line > 58 > > Warning: array_shift() expects parameter 1 to be array, null given in > Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 59 > > Warning: Invalid argument supplied for foreach() in > Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 61 > > Fatal error: Uncaught strpos() expects parameter 1 to be string, boolean > given > > Symfony2/src/Symfony/Bridge/PhpUnit/DeprecationErrorHandler.php:38 > > thrown in Symfony2/vendor/phpunit/phpunit/src/Framework/TestSuite.php > on line 871 > > > So yeah, to say "major BC issues" is the literal definition of an > understatement. > > > Thirdly, there are major reasons to upgrade to PHP 7, and we'd > > hopefully have some major reasons for people to upgrade for 8. There > > are going to be substantial carrots next to that breakage stick. > > Yes, and if we can avoid giving people breaks they can't trivially avoid > (via a > "compatibility checker" script, like minor syntax changes), then we're > just > making an artificial barrier for the sake of it. > > Rather than incentivizing the pain, why not avoid it? > > > Last, you appear to represent the 'can't be bothered' crowd, which I > > agree, is fairly large. But that crowd typically just doesn't > > upgrade, unless something or someone twists their arm. They don't > > upgrade even when there's no or very little compatibility breakage. > > That's why 5.3 is still so popular, and 5.2 isn't rare to find. Let > > alone 5.4. > > > > We have a track record that suggests that compatibility breakage slows > > adoption down, but it does not kill it as you suggest. > > > > > >> But they will not upgrade their code to PHP 7.1 or 8 then. > > > > Sooner or later they'd have to, if they want to maintain security. If > > they don't - it will not be the first time in history that people are > > negligent about their deployment (as the fact there are so many > > 5.2/5.3 deployments still out there proves), nothing unique for 7/7.1. > > Sure there is. We can make it easier for people. We can make their > experience with 7 significantly easier than 5.2. We can remove the stigma > and the fear associated with upgrading. We've been doing that since 5.4. > Smaller, easier and less painful breaks when they do exist. > Why not continue that? > > >> Ok, lets say 4-5 years. Given the lagging adoption of PHP major > >> versions, double this situation to 8-10 years in the wild. > > > > I do believe a 2-3 timeline for 8 (from when 7 is released) is a lot > > more likely than 4-5. > > The last time we had a major version was, as you know, 11 years ago. > > We can't deduce anything about adoption numbers from what we had back > then. > > We're also on a much more aggressive timeline nowadays, with support > > for each version stopping 3 years from when it gets initially > > released. At least based on what I'm seeing, adoption cycles appear > > to be significantly shorter than they used to be (1-3 years, not 4-5). > > I fully agree with you here. And if we take that stance, then each major > should get "lighter" in terms of what it breaks. To spur people to take > the > latest at all times, because they know it's stable and a minimal amount of > pain. > > > Of course, much like there are still users of 5.3, we're likely to > > have users of 7.0 even in 2025. That's not the point, and shouldn't > > play a role in the decision - it'd happen regardless. > > I think it absolutely plays a role in the decision. We should be making > lives > easier for our users, not making more work. Especially for the class of > user > that doesn't stay up to date. > > > Obviously not, but then, no RFC author that introduced breakage into > > PHP ever did, and there has been a lot of that going on, also in 7.0. > > I'm > > Hang on a second. All of the breaks that have gone into 7.0 were of two > classes up until now: > > 1. Those that were using deprecated functionality already 2. Those that > are > 100% statically fixable. > > You can write a "migration tool" to automatically fix the BC breaks in > Nikita's > patch. And in the PHP4 constructors patch. And in the reserved types > patch. > Together they are minor (with the exception of the php4 constructors patch > don't affect a lot of production code), but they are also 100% statically > fixable. > > This break is fundamentally different. It's by definition not statically > fixable > (at least without injecting casts everywhere, which is exactly the point > of the > patch, no?). So it's going to require a person physically fixing bugs > (easier if > there's a comprehensive test suite, really not easy if it's manual > testing). > > Thanks > > Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
