Re: [PHP-DEV] [RFC] Integer Semantics
On 22 Aug 2014, at 12:36, Derick Rethans der...@php.net wrote: Although I think it is good to make it work the same on every platform, I do think that changing it to *match* what the most used compiler (GCC) on our most used platform (Linux/AMD64) is what the new behaviour should be like — not something that looks best. I think that's what Laruence was trying to say as well. It causes the least amount of BC breaks for our users. That would also be a possibility. It’s not my favourite behaviour, but it’d at least be consistent. However, I wonder how many applications rely on the current behaviour on AMD64. It’s not terribly intuitive. For example, a shift by a negative number works like this on AMD64: $op1 ((PHP_INT_MAX + $op2) % 64) So, for example, were I to make $op2 be -1: $op1 ((PHP_INT_MAX + $op2) % 64) $op1 ((PHP_INT_MAX - 1) % 64) $op1 (9223372036854775806 % 64) $op1 62 Which is probably not what the user was expecting. Actually, I kinda lied, that’s just what *sane* compilers would do on AMD64. Negative bit shifts are undefined behaviour in the C standard, which gives the compiler an unlimited license to do absolutely anything it wants, including, for example, to not execute the shift altogether and assume it is dead code. In practise this is unlikely, however that is the standard. You make a good point that this is a BC break, though. This RFC in itself doesn’t make a super-compelling case, given it doesn’t really introduce any benefits (aside from the fact you can rely on $x $y, where $y = 64, equalling zero). It might be better if I retracted this RFC and kept these changes to the bigint RFC. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21/08/14 19:17, Stas Malyshev wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Wed, 20 Aug 2014, Andrea Faulds wrote: On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, 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 I'd like don't change the works behavior. make it act the similar as C does. For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all. Although I think it is good to make it work the same on every platform, I do think that changing it to *match* what the most used compiler (GCC) on our most used platform (Linux/AMD64) is what the new behaviour should be like — not something that looks best. I think that's what Laruence was trying to say as well. It causes the least amount of BC breaks for our users. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Tue, 19 Aug 2014, Andrea Faulds wrote: Good evening, 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 I think it is good to make sure it behaves the same on all systems. However, I think the behaviour should become what currently is the shift behaviour on the platform with our largest userbase: Linux on AMD64 with GCC. There is no reason to penalise people that well might have relied on some odd behaviour - possible even with good reasons. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
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
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21 August 2014 08:30, Derick Rethans der...@php.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21 Aug 2014, at 18:28, Adam Harvey ahar...@php.net wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 8/21/14, 11:09 AM, Levi Morrison wrote: 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.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
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 smalys...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
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
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
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
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On Thu, 21 Aug 2014, Marc Bennewitz wrote: 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. snip 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. snip 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 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 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 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On 20 Aug 2014, at 06:52, Dmitry Stogov dmi...@zend.com wrote: 1) INF conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? I think of Infinity as more of an error value than an actual number. Not using MAX_LONG and MIN_LONG means it casts to the same value matter how large the integer type is, and it happens to be what JavaScript casts Infinity to. There’s also the fringe benefit that 1/0’s result in PHP, FALSE, casts to zero, as Infinity now would also, which is the standard IEEE 754 result for 1/0. 3) a bit unrelated, but it also may make sense to introduce a logical right shift operator ( in Java) How would that function? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, 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 I'd like don't change the works behavior. make it act the similar as C does. For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all. The rest are “implementation-defined”. While what C does “works”, I’d rather we do one thing consistently instead of forcing developers to deal with the kinds of platform and compiler differences tools like PHP should be abstracting. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Wed, Aug 20, 2014 at 11:24 AM, Andrea Faulds a...@ajf.me wrote: On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, 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 I'd like don't change the works behavior. make it act the similar as C does. For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all. The rest are “implementation-defined”. While what C does “works”, I’d rather we do one thing consistently instead of forcing developers to deal with the kinds of platform and compiler differences tools like PHP should be abstracting. I totally agree with Andrea here. While it made sense to map C behavior for years, for many of us, as we all came from a C backgroud. However it makes less and less sense lately, if at all. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Wed, Aug 20, 2014 at 1:20 PM, Andrea Faulds a...@ajf.me wrote: On 20 Aug 2014, at 06:52, Dmitry Stogov dmi...@zend.com wrote: 1) INF conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? I think of Infinity as more of an error value than an actual number. Not using MAX_LONG and MIN_LONG means it casts to the same value matter how large the integer type is, and it happens to be what JavaScript casts Infinity to. There’s also the fringe benefit that 1/0’s result in PHP, FALSE, casts to zero, as Infinity now would also, which is the standard IEEE 754 result for 1/0. 3) a bit unrelated, but it also may make sense to introduce a logical right shift operator ( in Java) The difference between arithmetic and logical shift is sign propagation. 0x1000 1 == 0x1100 0x1000 1 == 0x0100 In C the same operator perform arithmetic shift for signed numbers and logical shift for unsigned. Thanks. Dmitry. How would that function? -- Andrea Faulds http://ajf.me/
[PHP-DEV] [RFC] Integer Semantics
Good evening, 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! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: Good evening, 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! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Makes sense to me. I was a little uneasy at first, but you made a very good point that a high-level language like PHP should be abstracting such environment-dependent differences away. And since you're targetting the next major release, BC isn't an issue. --Kris
Re: [PHP-DEV] [RFC] Integer Semantics
Hey: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, 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 I'd like don't change the works behavior. make it act the similar as C does. thanks Thoughts and questions are appreciated. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: https://wiki.php.net/rfc/integer_semantics In a perfect world, I'd rather see -X be equivalent to X, but since we do something very different currently, I think your approach of throw an error and ask questions later seems appropriate. The other ones all sound inarguable. +1 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
1) INF conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? 2) Negative shifts would be useful, as Sara mentioned. 3) a bit unrelated, but it also may make sense to introduce a logical right shift operator ( in Java) the rest seems fine, patch looks OK. Thanks. Dmitry. On Wed, Aug 20, 2014 at 8:05 AM, Sara Golemon poll...@php.net wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: https://wiki.php.net/rfc/integer_semantics In a perfect world, I'd rather see -X be equivalent to X, but since we do something very different currently, I think your approach of throw an error and ask questions later seems appropriate. The other ones all sound inarguable. +1 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
