Re: On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)

Hey: On Thu, Aug 21, 2014 at 11:30 PM, Derick Rethans <derick@php.net> wrote: > On Tue, 19 Aug 2014, Kris Craig <kris.craig@gmail.com> wrote: > >> On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds <ajf@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 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/