On Wed, Oct 9, 2019, at 2:50 AM, Zeev Suraski wrote: > As I wrote a couple of weeks back, before we agree on the principle - that > these contentious, breaking-for-no-new-reason proposals can’t be forced on > everyone but we need to make it opt-in, I don’t think formalizing it into > an RFC would help. I could be wrong, but I think we’re currently lacking > in good will on the other camp, which appears to feel a lot more > comfortable to just go on producing contentious proposals day in and day > out, and live with whatever sticks.
Tangent: I think it's a mischaracterization to divide opinions about PHP's future into "two camps", one of which wants to defend BC and never change anything and make the language as loosy-goosey as possible, and one that doesn't care about BC and wants to turn it into Haskell. Those are hyperbolic and incorrect descriptions of where I see people standing, and creating that "two warring camps" impression only makes the question about how PHP should evolve harder to resolve. There are several distinct axes of philosophical debate, and they do not necessarily correlate at all. 1) More BC protection vs less. 2) More opt-in "syntactic error checking" (eg, typing) vs less. 3) Fail hard on error cases vs "assume what was probably intended". 4) More "simplify common tasks" sugar vs less. 5) "performance reigns supreme" vs "spending performance to get usability is a good tradeoff". And probably many others I can't think of right now. Those various axes do not all correlate, and I suspect all 32 combinations of answers to those questions are represented by someone on this list, even before getting to the fact that they're all scales, not binaries, and some overlap in interesting ways (eg, failing hard is in some cases a BC break, others not). Zeev, you're very strongly and vocally on the "more BC protection" side. That's fine; I agree with you, by and large. But lumping "pfft, BC" in with "moar types" and "fail hard" and "moar sugar" and then dismissing them as "the other camp" does not advance the cause of BC protection, nor does it advance the cause of Internals not being a running gag of dysfunction, nor does it advance the cause of making PHP a better language, for any definition of better. As long as "anyone is allowed to propose an RFC", we *will* get RFCs that go against the informal consensus. Over time, that informal consensus will thus shift. That is an inevitable and unavoidable result of PHP's loosey-goosey structure. If you want to really protect BC, the way to do that is to actually put guidelines in writing that people have to read before proposing an RFC, and that we can point to when people ignore them anyway. But "that's how we've always done it, no it's not written down but we really have" is an approach doomed to not only fail, but to maximize the amount of strife as it fails. Let's please not do that. And developing such guidelines absolutely positively cannot happen on a public asynchronous mailing list. I've been through such processes enough times to know that is the worst possible way to do it. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
