Zeev, On Mon, Feb 23, 2015 at 5:53 PM, Zeev Suraski <z...@zend.com> wrote: > 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.
Well, my point was more that it's an indication of the scale of breaks to expect. > 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 :) My concern though is that if you do tweak the rules to get a reasonable amount of breakage, you're also going to remove all of the benefit of the type conversions you proposed. For example: A number of the issues that I saw with phpunit were related to passing bool to string and null to string. So to prevent those, you'd need to accept bool and null for strings. Which brings strings back precisely to the way they are today. So no changes. I saw the same things with int (specifically around debug_backtrace(false), where the first parameter is a bitmap). I couldn't get it to go far enough in (without spending 30 minutes debugging phpunit) to actually run a test. I tried disabling all bool/null checks in the patch, but am simply getting segfaults now. Will look at it a bit more later. > 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, I am concerned at this error rate we're seeing that we won't cause significant perf degradation due to the errors (even with reporting=0). And that's not mentioning log files. > 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. Sounds great. My concern here though is that my instinct says that either the rules are going to come out so similar to today's rules as to not be effective, or break enough code that it's not worth it. Please continue the patch, and let's test iterations. I just don't see where the magic line will be (not breaking too much while providing enough benefit to please the proponents of strict types). Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
