> -----Original Message----- > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > Sent: Monday, February 23, 2015 9:35 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > > > On Mon, Feb 23, 2015 at 7:09 PM, Zeev Suraski <z...@zend.com> wrote: > You're going to have several years to fix it. You could do it during a > bug > squash, at your leisure every once in a while, or the first day after > PHP 7 > comes out. Just like with any other deprecated feature. > > > > This is not how legacy code migrations work at all. You don't migrate > 100KLOC code just because the php version isnt compatible anymore. > You just don't upgrade. Now people might upgrade to PHP 7 because its > "just" E_DEPRECATED.
Benjamin, If you've been for a while on internals, you should know I'm a downwards compatibility freak. You don't need to explain to me about the nature of upgrades and how much downwards compatibility is important. But here, I disagree with you, for several reasons. If we implement this in PHP 7, assuming the most aggressive 2 year timeline for 8, 7.x will be supported until late 2019, and if it's a 3 cycle - late 2020. That's actually 5 years to migrate. Ample time for those who care about upgrades. 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. 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. 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. > How can you compare them? > > This changes E_STRICT to a E_WARNING. This is completely different than > changing E_DEPRECATED to E_RECOVERABLE_ERROR. If you read the RFC thoroughly, you'd see it contains elements that are exactly the same thing: * Promote to E_DEPRECATED if there is intent to remove this functionality in the future. // Non-static method Foo::method() should not be called statically Proposed resolution: Convert to E_DEPRECATED Possible alternative: Convert to E_DEPRECATED, if we intend to make this a fatal error in the future. > The first only requires to wrap an old library in $old = > error_reporting(0); > library(); error_reprting($old); > > The second leads to a fatal error. Are you seriously explaining to me how zend_error() works? :) > 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). 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. > Speaking as a consultant who helps people fix their legacy code I am > biased. > In my world nobody has tests. > And even those that have on their prorpiortary apps seldom have higher > coverage than 30-50%. Only very few have 80%. > > You cant compare open source code to what is out there, wordpress/drupal > is good code compared to all the propriortary code out there. I agree. But I am seeing better testing even in the darker corners of our tech world. Regardless, your customers either stick around with the old versions, or find a way to one way or another test the app - be it manually or otherwise. The former camp won't upgrade even to 7 - which isn't going to be a trivial upgrade thanks to already a fair amount of compatibility breakage in it. The latter camp will figure out ways to upgrade to 8, be it during the prolonged period of time where they can do it at their leisure, or at some distant point in the future where they are forced to do it because it's unsupported and a security exploit is discovered. > > I agree if we can avoid an INI setting, but this will surely lead to > a > > Python 2/3 > > situation. > > I don't think it will. But instead of guessing, we should try the patch > with some real world apps and find out. I think that if we find out we > can > migrate Drupal (or whatever) in a couple of days or even a couple of > weeks > to be E_DEPRECATED free - this approach is very viable. If it requires > months and months of updates, it'll be a different story. > > > > > "I don't think it will" is pretty subjective opinion. So is "this will surely lead to a Python 2/3 situation". I'd say this pushes the subjectiveness a couple of notches, too :) > You are betting on this > based on a hunch, without any data or way back, its extremely drastic > change you can't deny that. No, I'm not betting. And in fact I suggested a way to test your subjective absolute confidence statement vs. my subjective belief - test it out. > "We can migrate Drupal"? Are you volunteering to migrate the code of > everyone else as well? 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 obviously taking this as a test case, not as a service to the Drupal community. It could be WordPress of Drupal or whatever app we want to test, and it could be several of those. You appear fairly confident that we're going to see an end-of-the-world situation. I believe it will actually not take a lot of time to migrate. If we see that it takes a short time to migrate such apps, it's an excellent indicator as to the level of real world breakage that change would induce. Better than your guesstimate and surely better than mine. > Drupal Core is maybe 0.0001% of all php code out there, probably less. The > man hours spent reviewing and changing code add up to massive man days > of work. That's correct, but with substantial benefits - unlike most of our typical compatibility breakage. > Why are you suddenly so in favour of breaking BC so much when you where > strictly against this before? OK, so you do know my track record :) Simple - because it helps create a more consistent language, that's safer, and caters to the key needs of most of the people of both the strict and dynamic camps using a single rule-set. It's a very big deal, and I think it's at the very least worth exploring whether the price we'd have to pay for it. Most of our compatibility breakage is introduced for no other reason than warm fuzzy feeling or code cleanliness. It's really about a good bang for the buck ratio. Yes, it's probably more bucks than we usually pay for compatibility breakage, but it gives us a heck of a lot more bang in return. > My question to you: > > Why didn't you just repropose v1? According to your mails before it might > have run with a majority, so I dont see why this changes are necessary > that > are alienating more people than converting to the RFC. I actually don't see that much opposition to it. I saw quite a bit of support, with lots of feedbacks on how to fine tune the conversion rules - and a bunch of "PLEASE OH PLEASE NO INI ENTRIES", which I'm going to listen to (planning to go for the E_DEPRECATED option in 7.0, E_RECOVERABLE_ERROR in the future). Not saying there isn't opposition, but so far I've heard a lot more support than opposition. I think that voting for v0.1 right now - after all that's happened, would be divisive for the community. It would have been different if we had v0.3 split into v0.1 and then the v0.3 extras as a subsequent vote from the get go, but that's water under the bridge and isn't a good idea IMHO. It's clear we need a solution that pleases most people in both camps. I believe the Coercive STH RFC does a better job at that than the dual mode RFC. v0.1 doesn't. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
