On Mon, Feb 23, 2015 at 7:09 PM, Zeev Suraski <z...@zend.com> wrote: > > -----Original Message----- > > From: Benjamin Eberlei [mailto:kont...@beberlei.de] > > Sent: Monday, February 23, 2015 7:20 PM > > To: Zeev Suraski > > Cc: PHP internals > > Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC > > > > Just disabling E_DEPRECATED is hiding bugs now. > > It's an extreme interpretation. Deprecated features are not bugs > over-night. We never considered it that way. E_DEPRECATED notices aren't > bugs - they're friendly messages that the feature you relied on has limited > lifespan left in it. > The error gets triggered > > *because* somebody uses the wrong coercion rules, if i hide this, how am > i > > going to fix it? > > 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. But they will not upgrade their code to PHP 7.1 or 8 then. > > > Compare this to Smarty/FPDF/TCPDF. Extremly wide adoption libraries, > still > > php v4 code. > > They throw strict errors and notices like nothing you have ever seen > > before, > > but nobody talks about turning them into errors in PHP7/8. > > First, I've seen some pretty horrible stuff, so don't assume :) > But to the point, this: > wiki.php.net/rfc/reclassify_e_strict > > I'm not saying I necessarily support this RFC, but there's at least one > person talking about exactly the stuff supposedly nobody's talking about, > and that's without anything remotely close to the tangible benefits that > doing the internal function migration would bring. > 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. 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. > > > Furthermore, you said before this will be only 1-2 years, now until 8 we > > have > > another 8-10 years. > > There's no rulebook saying a major version needs to come out every 10 > years. > PHP 3 came out in 1998, PHP 4 came out in 2000, and PHP 5 came out in 2004. > PHP 5.3, which arguably should have been a major version, came out in 2009. > I think we should announce our plans for PHP 8 announced around the same > time as we release PHP 7. Not a concrete timeline like the one we have for > 7 right now, but high level plans. Given we're likely going to work on JIT > right after 7 comes out, we're going to have a trigger for 8 much sooner > than 2025 (not that personally I think we need a huge trigger for a major > version, but that's a different story). > > The 1 year figure is in the case we decide to change E_DEPRECATED to > E_RECOVERABLE_ERROR in 7.1 (which is an unlikely outcome). The 2 year > figure is realistic for PHP 8 given JIT, but if it's optimistic, it may be > 3 > and not 2. I doubt PHP 8 will take much longer than that, and can't > imagine > 10 years. > Ok, lets say 4-5 years. Given the lagging adoption of PHP major versions, double this situation to 8-10 years in the wild. > > > > 8% is alot. Now you are lucky that you have unit tests. The kind of code > > that > > will rely on this conversion probably does not have a single test. > > I'm talking about the PHP unit test suite, and while 8% failure rate on a > test suite is generally a lot, I wouldn't consider it a high number for > such > an impactful patch that has not yet been tuned. Also assume we have until > the end of the year to potentially tweak certain internal functions to be > more lax than the rules they currently expose, which may make sense in some > cases where we may find widespread breakage associated with specific APIs. > I believe we can get it much lower than 8% by tweaking the rules and > tweaking some internal functions. > Regarding other apps - many of the major apps today do have unit test > suites, and I'm seeing unit and system tests a lot more today than 5 or 10 > years ago. 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. > We'll only truly know where we stand once we actually try > running some of the major apps and real world code see how many > E_DEPRECATED > messages we're getting. If we see a few dozen E_DEPRECATED's for a decent > size apps - the feasibility of migrating it (whether immediately, during > the > 2-3 year term or when people move to 8 and are forced to do so) is there. > Not unlike many of the countless other features we've deprecated in 7 - > most > of which for no reason other than code tidiness. > > > magic quotes has a workaround you can put into an auto_prepend_file, > > *magically* making it work this way before again. > > This changes here have no workaround to keep the old mode. > > magic_quotes_gpc did, magic_quotes_runtime did not. safe_mode didn't > either, and it was extremely widely used. > Fair point. > > > I'm personally now leaning towards this option as the most viable > > one. > > > > > > 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. You are betting on this based on a hunch, without any data or way back, its extremely drastic change you can't deny that. "We can migrate Drupal"? Are you volunteering to migrate the code of everyone else as well? 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. Why are you suddenly so in favour of breaking BC so much when you where strictly against this before? 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. > Zeev >
