# On BC and not being evil (Was: Re: [RFC] Integer Semantics) - Thread: https://externals.io/message/76753 - Original archive: https://news-web.php.net/php.internals/76753 - Started by Derick Rethans on 2014-08-21T15:30:07+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76753 — Derick Rethans — 2014-08-21T15:30:07+00:00 URL: https://externals.io/message/76753#76753 > > > > […] > > > > And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that "Backwards Compatibility is not an issue" with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be "oh we have a major new version so we can break all the things"™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple "default" cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the "Uniform Variable Syntax", that I already `wrote about`_, the current discussion on `"Binary String Comparison"`_, and now changing the `behaviour`_ on ``<<`` and ``>>`` in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with "But Symfony and ZendFramework don't use this" either, as there is so much code out there As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science "purity" reasons to "make things better" have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding ``<<`` and ``>>`` is not one of those, and subtle changes to what syntax means is certainly not one of them. **Don't be Evil** cheers, Derick --- ## #76755 — Adam Harvey — 2014-08-21T17:28:59+00:00 URL: https://externals.io/message/76753#76755 · In reply to: #76753 > Can I please urge people to not take Backwards Compatibility issues so > lightly. Please think really careful when you suggest to break Backwards > Compatibility, it should only be considered if there is a real and > important reason to do so. Changing binary comparison is not one of > those, changing behaviour for everybody regarding ``<<`` and ``>>`` is > not one of those, and subtle changes to what syntax means is certainly > not one of them. > > **Don't be Evil** +1 on everything Derick said. I want to make one more point: if there's just one thing we learn from other languages that have made BC-breaking, major version transitions, it should be that library and framework authors will ultimately have to support both versions in the same code base. Python tried using tooling such as 2to3 to help manage the transition, but in the end the only way Python 3 has gotten any traction is libraries supporting both, which effectively means that library authors can only write the subset of Python that's supported by 2 and 3. Every time we break BC — in either of the ways Derick said — we narrow the subset of PHP 5 and PHP 7 that's available to people writing PHP code that has to work on both. If we narrow it too far, it'll be too unexpressive, or too hard to use, or just plain won't do something that they'll need, and PHP 7 will risk becoming this decade's Perl 6: the cautionary tale for what happens when you burn all the boats. PHP 7 is an opportunity. It needs to be one that we embrace, and take advantage of, but most importantly one that is evolutionary and allows our user base to come with us. Adam --- ## #76757 — Andrea Faulds — 2014-08-21T17:47:27+00:00 URL: https://externals.io/message/76753#76757 · In reply to: #76755 > Every time we break BC — in either of the ways Derick said — we narrow > the subset of PHP 5 and PHP 7 that's available to people writing PHP > code that has to work on both. If we narrow it too far, it'll be too > unexpressive, or too hard to use, or just plain won't do something > that they'll need, and PHP 7 will risk becoming this decade's Perl 6: > the cautionary tale for what happens when you burn all the boats. Not all BC breaks prevent code from being both forwards- and backwards-compatible, however. In some cases, the new way to do something works correctly in old versions as well. -- Andrea Faulds http://ajf.me/ --- ## #76764 — Levi Morrison — 2014-08-21T18:09:19+00:00 URL: https://externals.io/message/76753#76764 · In reply to: #76755 > Every time we break BC — in either of the ways Derick said — we narrow > the subset of PHP 5 and PHP 7 that's available to people writing PHP > code that has to work on both. If we narrow it too far, it'll be too > unexpressive, or too hard to use, or just plain won't do something > that they'll need, and PHP 7 will risk becoming this decade's Perl 6: > the cautionary tale for what happens when you burn all the boats. I agree with this idea principle. I disagree that these RFCs are breaking so much backwards compatibility to create the next Perl 6. --- ## #76767 — christopher jones — 2014-08-21T18:14:41+00:00 URL: https://externals.io/message/76753#76767 · In reply to: #76764 > > […] > > I agree with this idea principle. > > I disagree that these RFCs are breaking so much backwards > compatibility to create the next Perl 6. > Cumulatively they could easily break BC in the way Derick mentioned. BC issues will mount up unless a higher level overview is considered about the release. -- christopher.jones@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #76769 — Stas Malyshev — 2014-08-21T18:17:41+00:00 URL: https://externals.io/message/76753#76769 · In reply to: #76753 Hi! > > […] > > This sort of blanket statements that "Backwards Compatibility is not an > issue" with a new major version is extremely unwarranted. *Extreme care* > should be taken when deciding to break Backwards Compatibility. It > should not be "oh we have a major new version so we can break all the > things"™. I agree. Major means we *can* break BC, if there's a reason good enough, but that doesn't mean we get to break BC *for free*. We do need to carefully weight it each time and ensure it is worth it, not dismiss it with "oh, it's PHP 7, so we can do anything we want, BC is no longer a concern". We have millions of people using PHP 5, and the goal is for almost all of them to eventually use PHP 7, otherwise there's no point in it. Each BC break creates another hurdle on the way to it. We should take it seriously. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #76778 — Trevor Suarez — 2014-08-21T19:23:42+00:00 URL: https://externals.io/message/76753#76778 · In reply to: #76769 What if we were to *quantify* backwards compatibility in a way, as opposed to just discussing the hypothetical BC breaking potential of a change? I've never thought of this before, but this discussion had me thinking... When I write a library that has a large user base, I try to write as many unit tests and potential regression tests as possible. Unfortunately, the larger the user base and the larger the feature set, the more coverage is necessary. A language like PHP, it would be nearly unlimited. But stay with me here. What's better than a simple unit of testing or benchmarking? Most of us know that not much really beats real world application testing, or at least a more realistic form of feature use. This is where the Hack team got it right. Hack, during its early development (and even still) used a suite of PHP frameworks, libraries, and well known projects to test their PHP compatibility. Ironically, I believe that Hack originally used these types of test due to a lack of a language specification: there was no other way to really make sure to match the language's behavior. However I think that this type of testing is valuable anyway. What if we were to create a (or "borrow" Hack's) framework testing suite and run PHP 7 and upcoming RFC patches against the suite before accepting them. Yes, likely things will fail with BC breaks, but then the PHP internals team (or the RFC writer, hopefully) could then see exactly what was being used in a given framework that might break. Even better, the internals/RFC developer could see how much effort would be required to fix the BC break in the broken tested framework and could gauge whether the break was worthwhile or not a lot more. Finally, even more importantly, we could see the range of libraries and frameworks that would break with a given change and even introduce a potential RFC rule for BC breaking (on major versions, etc)... like we have with rules around certain voting majorities based on the type of language change, we could have a certain percentage of libs/frameworks that would have to be compatible (or somehow quantify the effort needed to update each [can it be automated via a tool or not]). Anyway, just spit balling here. I know it would take effort, but this could make a huge difference in our "oops" moments and quality checking for the language updates. Hell, maybe it would even make us more apt to "greenlight" features that we'd otherwise be afraid of because we'd see that it wouldn't be as big of a deal as we thought. Overall I think this would reduce a lot of the conjecture and discussion/fear around possible BC breaks that could help or hurt the project and the future of the language. *Trevor Suarez* +Trevor Suarez @trevorsuarez On Thu, Aug 21, 2014 at 2:17 PM, Stas Malyshev wrote: > Hi! > > > […] > > I agree. Major means we *can* break BC, if there's a reason good enough, > but that doesn't mean we get to break BC *for free*. We do need to > carefully weight it each time and ensure it is worth it, not dismiss it > with "oh, it's PHP 7, so we can do anything we want, BC is no longer a > concern". We have millions of people using PHP 5, and the goal is for > almost all of them to eventually use PHP 7, otherwise there's no point > in it. Each BC break creates another hurdle on the way to it. We should > take it seriously. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ --- ## #76780 — Kris Craig — 2014-08-21T19:41:35+00:00 URL: https://externals.io/message/76753#76780 · In reply to: #76753 > > > > […] > > This sort of blanket statements that "Backwards Compatibility is not an > issue" with a new major version is extremely unwarranted. *Extreme care* > should be taken when deciding to break Backwards Compatibility. It > should not be "oh we have a major new version so we can break all the > things"™. > > There are two main types of breaking Backwards Compatibility: > > 1. The obvious case where running things trough ``php -l`` instantly > tells you your code no longer works. Bugs like the two default cases, > fall in this category. I have no problem with this, as it's very easy > to spot the difference (In the case of allowing multiple "default" > cases, it's a fricking bug fix too). > > 2. Subtle changes in how PHP behaves. There is large amount of those > things currently under discussion. There is the nearly undetectable > change of the "Uniform Variable Syntax", that I already `wrote > about`_, the current discussion on `"Binary String Comparison"`_, > and now changing the `behaviour`_ on ``<<`` and ``>>`` in a subtle > way. These changes are *not okay*, because they are nearly > impossible to test for. > > Changes that are so difficult to detect, mean that our users need to > re-audit and check their whole code base. It makes people not want to > upgrade to a newer version as there would be more overhead than > gains. Heck, even changing the ``$`` in front of variables to ``£`` > is a better change, as it's *immediately* apparent that stuff > changed. And you can't get away with "But Symfony and ZendFramework > don't use this" either, as there is so much code out there > > As I said, the first type isn't much of a problem, as it's easy to find > what causes such Backwards Compatibility break, but the second type is > what causes our users an enormous amount of frustration. Which then > results in a lot slower adoption rate—if they bother upgrading at all. > Computer Science "purity" reasons to "make things better" have little to > no meaning for PHP, as it's clearly not designed in the first place. > > Can I please urge people to not take Backwards Compatibility issues so > lightly. Please think really careful when you suggest to break Backwards > Compatibility, it should only be considered if there is a real and > important reason to do so. Changing binary comparison is not one of > those, changing behaviour for everybody regarding ``<<`` and ``>>`` is > not one of those, and subtle changes to what syntax means is certainly > not one of them. > > **Don't be Evil** > > > cheers, > Derick > > -- > > > Derick, I think you misunderstood my meaning. It was never my intention to imply that BC doesn't matter or that it should be taken lightly. My statement that it's not an issue was in the context of this RFC, which people seem to overwhelmingly agree is a good idea. When you have a beneficial idea that people like, implemented in a major version increment, BC is not an issue. That's what I meant and I stand by that. That said, I don't disagree with your larger points about BC being a consideration even in major release increments. However, I also feel the need to point out that, historically, there have been a lot of known issues in PHP that we've decided not to fix even in major increments because of what I believe to be an excess of BC concern. One example-- it's almost a cliche at this point-- is the inconsistent function naming and argument orders. In my experience, that's been the most common complaint I hear from PHP devs. We've avoided cleaning that up because it would break all kinds of stuff. While I agree that BC should never be decided on lightly, I do believe that an expectation exists that significant code updates will have to be made by framework/etc maintainers when upgrading to a new major release. So I do think we should allow ourselves to finally correct these lingering issues for the next major release. It will slow adoption in the short-term, but it is the right strategy for the language in the long-term. TL;DR: BC does matter and should never be taken lightly, but we should also not be afraid to introduce some BC in a major release in order to correct various longstanding issues. --Kris --- ## #76783 — Derick Rethans — 2014-08-21T20:55:15+00:00 URL: https://externals.io/message/76753#76783 > > > […] > > […] > I'm on you if you say "Please think really careful when you suggest to break > Backwards Compatibility". It's very important in so much ways. *BUT* you are > very unlikely in the cost of the 2 RFCs. The "cost"? > First I don't see an comment of you in the Binary String Comparison > RFC and I think you should do your misgivings there instead of wring > this untopic. Each BC break should be discussed carefully by it's own! Because it's not worth my time. I don't feel it necessary to comment if so many people already have spoken out against it: Julien[1], Sara[2], Rasmus[3], Adrian[4], Johannes[5]. Frankly, I don't understand why you haven't given up on this as nobody has shown support. [1] http://news.php.net/php.internals/76639 [2] http://news.php.net/php.internals/76613 [3] http://news.php.net/php.internals/76615 [4] http://news.php.net/php.internals/76614 [5] http://news.php.net/php.internals/76658 cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #76786 — Laruence — 2014-08-22T02:26:43+00:00 URL: https://externals.io/message/76753#76786 · In reply to: #76753 Hey: > > > > […] > > This sort of blanket statements that "Backwards Compatibility is not an > issue" with a new major version is extremely unwarranted. *Extreme care* > should be taken when deciding to break Backwards Compatibility. It > should not be "oh we have a major new version so we can break all the > things"™. > > There are two main types of breaking Backwards Compatibility: > > 1. The obvious case where running things trough ``php -l`` instantly > tells you your code no longer works. Bugs like the two default cases, > fall in this category. I have no problem with this, as it's very easy > to spot the difference (In the case of allowing multiple "default" > cases, it's a fricking bug fix too). > > 2. Subtle changes in how PHP behaves. There is large amount of those > things currently under discussion. There is the nearly undetectable > change of the "Uniform Variable Syntax", that I already `wrote > about`_, the current discussion on `"Binary String Comparison"`_, > and now changing the `behaviour`_ on ``<<`` and ``>>`` in a subtle > way. These changes are *not okay*, because they are nearly > impossible to test for. > > Changes that are so difficult to detect, mean that our users need to > re-audit and check their whole code base. It makes people not want to > upgrade to a newer version as there would be more overhead than > gains. Heck, even changing the ``$`` in front of variables to ``£`` > is a better change, as it's *immediately* apparent that stuff > changed. And you can't get away with "But Symfony and ZendFramework > don't use this" either, as there is so much code out there I am totally agree with Derick here. We should avoid to change such basic behaves.. thanks > > As I said, the first type isn't much of a problem, as it's easy to find > what causes such Backwards Compatibility break, but the second type is > what causes our users an enormous amount of frustration. Which then > results in a lot slower adoption rate—if they bother upgrading at all. > Computer Science "purity" reasons to "make things better" have little to > no meaning for PHP, as it's clearly not designed in the first place. > > Can I please urge people to not take Backwards Compatibility issues so > lightly. Please think really careful when you suggest to break Backwards > Compatibility, it should only be considered if there is a real and > important reason to do so. Changing binary comparison is not one of > those, changing behaviour for everybody regarding ``<<`` and ``>>`` is > not one of those, and subtle changes to what syntax means is certainly > not one of them. > > **Don't be Evil** > > > cheers, > Derick > > -- > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #76795 — Lester Caine — 2014-08-22T09:36:38+00:00 URL: https://externals.io/message/76753#76795 · In reply to: #76769 > We have millions of people using PHP 5, and the goal is for > almost all of them to eventually use PHP 7, otherwise there's no point > in it. Each BC break creates another hurdle on the way to it. We should > take it seriously. Currently we have millions still using 5.2 because the changes to 5.3/4 require work. 'strict' while something one can switch off HAS to be reworked for in order to move that code forward and remove the problems caused by third party hosting changes that may well be out of a users control. Many of the changes being put forward will probably not affect older code, as it's not been using these 'improvements' anyway, but it would be nice if as part of the PHP7 process there was a mechanism which could scan the code and at least tag what areas need attention rather than the current mechanism of having to keep one eye on the error logs for changes that have been missed. I think Derick is picking up subtle changes almost to style which are difficult to detect but will result in changes in outcome, and those sorts of changes need the most support to identify if they go forward? It looks like I've lost PHPEclipse as a mechanism that could provide this level of checking as it seems to have lost support, and I still don't find PDT as capable in this sort of area :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk