On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > > 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 *will* break some code. There's no chance that somebody somewhere > doesn't use this. And the change would break it. Worse yet, he won't be > able to know about it until the customer complains about code logic > being broken. > On what basis are you making that claim with such certitude? In all my years, I have yet to encounter a single, solitary case where someone's actually relying on PHP's wonky, counter-intuitive, non-standard associativity with the ternary operator. If such a one-in-a-billion scripts does exist somewhere, it's likely some PHP 4 thing that hasn't been touched in years. > > > 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, > > 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. > > > 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 > > 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. I think, > however, it's better than actually suffering these consequences. > Consider that however ugly this particular wart is, people has been > living with it for almost 20 years, and it may be preferable for them to > have somewhat ugly code than having broken code. > I don't think the "we've been sick so long we're used to it now" argument is very compelling. Some BC is expected in major revisions; and, historically, we have been WAY too conservative about that, in my view. When there's a major version and there's a BC-breaking change that either fixes something many people have been complaining about or improves the language in some other way without losing its identity, it should be a go. Major revisions are when changes like this are supposed to be made because, otherwise, these problems remain forever. I don't think it's rational to continue to ignore one of the most-requested fixes to PHP because one or two people out there may be relying on the broken behavior-- and yes, it is broken in the sense that it does not behave in the manner it's expected to for a C-like syntax. Didn't we talk about doing polls before? We should do a poll on this in the PHP community and see who, if anyone, has any code anywhere that relies on this confusingly counter-intuitive behavior. I would be amazed if even one person answered yes to that. So rather than continuing to guess and make unfounded assumptions, why don't we just ask them and settle the question here and now? --Kris > > 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. > > Sorry, but arguing from "do this or that or I'm quitting" does not seem > a very strong argument to me. More drama does not help to evaluate the > merits of changing the associativity of ?:. I think everybody here > values the time of the volunteers that continue to contribute to the > project, but I think keeping the discussion on the technical merits > would be better. > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
