<snip>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!
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:
-
The obvious case where running things trough
php -linstantly
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). -
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 alreadywrote about, the current discussion on"Binary String Comparison",
and now changing thebehaviour_ 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
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
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/
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.
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.
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
Hi!
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"™.
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/
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 https://plus.google.com/+TrevorSuarez
@trevorsuarez https://twitter.com/trevorsuarez
On Thu, Aug 21, 2014 at 2:17 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
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"™.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/
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
<snip>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!
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:
The obvious case where running things trough
php -linstantly
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).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 alreadywrote about, the current discussion on"Binary String Comparison",
and now changing thebehaviour_ 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 thereAs 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
Hey:
<snip>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!
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:
The obvious case where running things trough
php -linstantly
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).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 alreadywrote about, the current discussion on"Binary String Comparison",
and now changing thebehaviour_ 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/