On Thu, Aug 21, 2014 at 8:30 AM, Derick Rethans <der...@php.net> wrote:
> On Tue, 19 Aug 2014, Kris Craig <kris.cr...@gmail.com> wrote: > > > On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds <a...@ajf.me> wrote: > > > > > I have made an RFC which would make some small changes to how integers > > > are handled, targeted at PHP 7: > > > > > > https://wiki.php.net/rfc/integer_semantics > > > > > > Thoughts and questions are appreciated. Thanks! > > > > <snip> > > > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > 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
