[PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
Hi guys, I was wondering if 7.0 could be the version to fix the long-standing incorrect ternary associativity bug in PHP [1]. This seems especially worthy of reconsideration since the Null Coalesce RFC has been accepted and merged [2] with the correct associativity [3]. The major version change seems like the only time to get this done in PHP. [1] https://bugs.php.net/bug.php?id=61915 [2] https://wiki.php.net/rfc/isset_ternary [3] http://news.php.net/php.internals/79584 thanks, -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
Respectfully, PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating; the utterly ridiculous T_PAAMAYIM_NEKUDOTAYIM argument comes to mind. It is not a bug, as the issue's status says: Not a bug. I can understand why this would have been a 'wontfix' for versions pre-7.0. However, major version changes are done primarily to fix these kinds of inconsistencies - that and marketing - and yes they are precisely that: bugs. Documentation of unexpected behavior does not make something 'not a bug'. I and countless other PHP devs simply avoid using these easily correctable, useful language features because they are cumbersome, unexpected and actively discouraged in the documentation itself; how the sum of these facts doesn't qualify as a bug is outside all but the narrowest, most bizarre definitions of 'bug' that exists in any software community. The fact that it *may* break *some* code that is used somewhere despite documentation recommending against it (pretty much deprecating it already for years) is a terrible reason not to re-evaluate the situation given the huge opportunity to correct this. It's another one of those bonkers changes. It changes behaviour of already existing syntax. This sort of meddling with the language is difficult to detect, and there is little value in fixing it. Don't piss off users for purety. The only thing that's bonkers here is outright refusal to make trivially breaking changes (in addition to numerous other breaking changes already accepted) simply for the sake of not breaking some 0.1% of outdated, against-recommendation code. This is not an argument for purity - I want a working-as-expected ternary syntax as a feature, right now it is an un-feature and is a caveat that must be documented - it is a wart. If the goal was purity, PHP wouldn't even make the list of languages I would consider. Rather than simply pointing to a 3-year-old close-reason, it would be prudent to actually get statistics on how often this unexpected behavior is relied upon in large, popular codebases. Packagist Github, that didnt exist significantly in the PHP community in 2012, would be a good place to start. It would not even be outside the realm of possibility to do a bit of evangelism via Github issues if such cases are found so they can be fixed with a 1-year notice. It's short responses like this and the continued reliance on arguments posed in a different era/landscape that compel me to reconsider my continued participation in the PHP community at all. cheers, -- Leon Sorokin On 12/13/2014 5:20 PM, Derick Rethans wrote: On Sat, 13 Dec 2014, Leon Sorokin wrote: I was wondering if 7.0 could be the version to fix the long-standing incorrect ternary associativity bug in PHP [1]. It is not a bug, as the issue's status says: Not a bug. This seems especially worthy of reconsideration since the Null Coalesce RFC has been accepted and merged [2] with the correct associativity [3]. It's another one of those bonkers changes. It changes behaviour of already existing syntax. This sort of meddling with the language is difficult to detect, and there is little value in fixing it. Don't piss off users for purety. I suggest you read this too: http://derickrethans.nl/bc-dont-be-evil.html The major version change seems like the only time to get this done in PHP. Only time it is *allowed*; that doesn't it should be done. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/14/2014 12:51 AM, Levi Morrison wrote: While I think long-term this would be a beneficial change I think in the short term it's quite a hurdle. This discussion will be identical whether we wait till PHP7 or PHP9 in a decade. The longer this change takes to make, the more code that will be mis-written to rely on the current behavior. If any long-term benefit is to be reaped, now is the best time to do it - every future major version will have a harder justification to make. There is definitely code out there relying on this behavior and changing it will result in the worst BC case: it will not fail in any way but will instead act differently. There are also definitely IE5.5 users out there and websites that rely on IE5.5-only features, but the actual numbers matter. There's no doubt that somebody, somewhere is going to have broken code because they wrote it without reading the docs that recommend against it or without understanding how it works, or upgraded without reading a migration guide or realizing that major version upgrades do make breaking changes (more often than not). These people do exist and they may curse PHP rather than themselves and leave it forever; the desire of the core team to retain the maximum amount of these users is puzzling. The change under discussion will not be causing any sort of mass-exodus from PHP, the ecosystem will not collapse and it will not be the heat-death of the universe. It will be removing a long-discouraged behavior and bring expected uniformity to a common construct that has differed for no good reason from other languages. There's plenty of room for a #5 on the already non-0 list: https://wiki.php.net/phpng#incompatibilities_made_on_purpose_and_are_not_going_to_be_fixed In my opinion, chaining or nesting ternaries at all should be discouraged; changing the associativity doesn't change the fact that they are more difficult to follow and more error prone than using different constructs. I would disagree on this point. Just like there are cases where a large switch/case results in more readable if-elseif chains, long conditional assignment chains can serve the same purpose, granted you space them appropriately. I would even go as far as saying that with proper spacing, they are more readable than the 'if' or 'case' blocks that would need to replace them. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
This sounds like a reasonable compromise to me and infinitely better than doing nothing. However, if 7.0 complains loudly enough about this already quasi-deprecated pattern, then the incubation period for an eventual fix need not be that of a decade-out major version, but of a 7.x point release. Oddly, 5.4 is a good example of a much larger incompatibility changelog than the provisional one for 7.0: http://php.net/manual/en/migration54.incompatible.php -- Leon Sorokin On 12/14/2014 6:01 AM, George Bond wrote: On 14 December 2014 at 08:24, Leon Sorokin leeon...@gmail.com wrote: On 12/14/2014 12:51 AM, Levi Morrison wrote: While I think long-term this would be a beneficial change I think in the short term it's quite a hurdle. This discussion will be identical whether we wait till PHP7 or PHP9 in a decade. The longer this change takes to make, the more code that will be mis-written to rely on the current behavior. If any long-term benefit is to be reaped, now is the best time to do it - every future major version will have a harder justification to make. There is definitely code out there relying on this behavior and changing it will result in the worst BC case: it will not fail in any way but will instead act differently. There are also definitely IE5.5 users out there and websites that rely on IE5.5-only features, but the actual numbers matter. There's no doubt that somebody, somewhere is going to have broken code because they wrote it without reading the docs that recommend against it or without understanding how it works, or upgraded without reading a migration guide or realizing that major version upgrades do make breaking changes (more often than not). These people do exist and they may curse PHP rather than themselves and leave it forever; the desire of the core team to retain the maximum amount of these users is puzzling. The change under discussion will not be causing any sort of mass-exodus from PHP, the ecosystem will not collapse and it will not be the heat-death of the universe. It will be removing a long-discouraged behavior and bring expected uniformity to a common construct that has differed for no good reason from other languages. There's plenty of room for a #5 on the already non-0 list: https://wiki.php.net/phpng#incompatibilities_made_on_ purpose_and_are_not_going_to_be_fixed In my opinion, chaining or nesting ternaries at all should be discouraged; changing the associativity doesn't change the fact that they are more difficult to follow and more error prone than using different constructs. I would disagree on this point. Just like there are cases where a large switch/case results in more readable if-elseif chains, long conditional assignment chains can serve the same purpose, granted you space them appropriately. I would even go as far as saying that with proper spacing, they are more readable than the 'if' or 'case' blocks that would need to replace them. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php If you wanted an upgrade path that was not Evil (in the sense of not introducing subtle and hard-to-diagnose bugs), could you not change the operator to be *un*associative in PHP7? That would effectively just make concrete the discouragement/deprecation that's already in the documentation, and would produce irritating but very visible errors for anyone still actually using this functionality, as well as making them alter their code in a forward-compatible way. Then if you want to think really long term, plan to implement the 'correct' associativity in the *next* major version. --G -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/14/2014 10:45 PM, Robert Williams wrote: I strongly suspect far more code would be *fixed* if the ternary operator were changed to match what other languages do. I appreciate your support, but either I am not understanding you, or your reasoning is unsound. If you have 'incorrectly' functioning code today that results in passing unit tests and a correctly functioning business. Then a sudden change to the behavior of this code would necessarily result in failing unit tests and an incorrectly functioning business. The code may be 'fixed' from a semantic point of view, but the logic would be broken from a required-output point of view relative to how it was operating previously, regardless of whether it was understood or not when it was written. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/15/2014 2:11 PM, Stanislav Malyshev wrote: There's not that many breaking changes accepted, and each of them had to be substantiated. We had other breaking changes is not a substantiation. For example, most uses of associativity are wrong ones - is, but that makes the idea of un-associating it even better, since unlike changing the associativity, it actually makes the problem obvious and easy to fix. Alternatively, of course, we could make a tool that detects this and alerts the user, but making it loud still sounds better. And the breakage we are discussing is not trivial - it's a logic change which makes code silently take different codepath without anybody knowing. In the world of BC breaks, this is one of the most evil ones. So we should avoid it as much as possible. The justification for not making breaking changes always grows as a function amount-of-code-in-the-wild which could possibly be relying on bugs. This situation results in a permanent conclusion of 'better-never' in lieu of 'better-now-than-later'. In PHP-land, the implication then is that this gridlock cannot be resolved even by major versions (IMO, one of very few reasons for major versions to exist *at all*). Usually the burden of proof lays on whoever proposes the change. Note that a lot of code is not public, especially for languages like PHP that is used for websites - meaning, there's little reason to publicize any code but reusable library code. And the fact that the change would not break a handful of popular libraries doesn't mean it won't break scores of websites whose source you can not see, but which are way more important for the people using them than some library they don't use. Yes, I understand that this means very high burden on somebody proposing BC-breaking change, and it makes the development more conservative. It is a high burden convince people that this change is worth the risk of breaking potentially unknown code with unknown consequences. Without telemetry, there is obviously no way of *ever* asserting that something is ripe for removal or even deprecation. So this burden of proof is unmeetable by definition. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/15/2014 11:59 AM, Robert Williams wrote:
What world is this that you live in where every line of code that’s written is
fully unit-tested
You took my example too literally; forget the unit tests. Imagine the
situation differently:
1. Someone wrote this function:
function add_five_pct($num) {
return $num * 1.10;
}
2. This function was then used to calculate profit margin and display
retail prices on your site and business has been great! Unknowingly,
you've been making 2x what was intended with no ill effects!
3. A new hire then went through this code on his own accord and decided,
'wait, this function is a bug!' and took it upon himself to fix it to
'$num * 1.05'.
Would you say the e-commerce site has been 'fixed' to work correctly?
Should the dev be praised for fixing the clearly broken function without
consulting anyone?
I cannot come up with a clearer explanation of how a 'silent' code fix
can foul up the bigger picture in non-beneficial ways. That's the
scenario that's being discussed here. The main point of contention is,
no one knows how much code exists in the wild that uses and relies on
this misbehavior. My argument is 'negligible', others say it's
'non-negligible'. And the whole comedy is, no one can actually provide
definitive numbers since nobody will ever know but a tiny portion of all
source code that is out there, so all arguments stem from 'meta'
evidence and personal experience.
--
Leon Sorokin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] PHP 5.7
On 12/30/2014 2:26 AM, Stanislav Malyshev wrote: I still haven't achieved a proper understanding of what 5.7 would actually include (so far the only real BC thing mentioned that it can warn about is the switch thing, and IMHO making the new minor just because of that makes little sense, of course I'm not counting non-accepted RFCs since otherwise there's like 40 of them), so I intend to vote no, but if somebody really sees something substantial that I missed, please point me out, as I am not opposed to the idea of 5.7 just don't see any practical content for it for now. Would the unassociation or deprecation-for-unassociation of the ternary '?' (discussed in another thread [1]) be appropriate for the 5.7? Kris Craig mentioned he would write up an RFC for this when he has a chance. [1] http://grokbase.com/t/php/php-internals/14cdp789nk/fix-incorrect-ternary-associativity-for-7-0 thanks, Leon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] imap_fetchbody() leaks memory
On 1/23/2017 2:45 PM, Michael Wallner wrote: Just assigned that to me, I'll try to come to it the next few days. Great, thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] imap_fetchbody() leaks memory
Hey guys, I filed bug 73493 [1] a couple months ago and there's no triage or visible activity yet. Was hoping to get an update if possible. I'm forced to download any large INBOX in batches with imap_close() & imap_open() gymnastics to avoid chewing through 2GB+ of RAM. thanks! [1] https://bugs.php.net/bug.php?id=73493 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] imap_fetchbody() leaks memory
On 1/25/2017 3:52 AM, Michael Wallner wrote: Hi, I've updated the bug: https://bugs.php.net/bug.php?id=73493 TL;DR The c-client lib performs a lot of caching; use imap_gc() to clean those caches from time to time. Ok, great. Will give that a try. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
