On Sat, Dec 13, 2014 at 4:53 PM, Leon Sorokin <leeon...@gmail.com> wrote: > > 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.00001% 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 > > Ok I'm going to draft an RFC for this when I have a spare moment. This is exactly the sort of contentious issue that the RFC process was created to help resolve. We'll bring it to a vote and everyone will make their arguments. If 2/3 vote to change the behavior, that'll be that. I respect Derrick's position on this but I could not disagree with it more.
--Kris
