> -----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. > 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. > 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. > 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. 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. > 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. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
