On 21.08.2014 17:30, Derick Rethans 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.
Derick,
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. 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!
Marc
**Don't be Evil**
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
