> On Oct 8, 2019, at 5:34 PM, Zeev Suraski <z...@php.net> wrote: > So while I sympathize with the effort to find a compromise - encouraging more > of these contentious proposals (by accommodating them at some level) is not > the way.
Ok, but... > The real middle ground is to go for some form of opt-in solution. Whether > it’s granular declares, strict mode, P++, editions - this is the only way to > diffuse this contention - by rendering it irrelevant - precisely as it should > be. Contrary to the perception many here appear to be under, there’s no > feasibility question-mark over any of these options - they’re all doable, and > even easy to implement. This solution would also not be some band aid until > the next out of the blue proposal comes along - but a framework to thoroughly > diffuse these types of contention once and for all. ...it seems you have identified at least one way to seek compromise. Why not move forward with this, in general? Said another way, why not discuss and debate BC breakage in abstract — and any other contention topics — and then establish a set of principles that the community can agree to use? This could be done in an RFC, and much like Mission, Vision and Values statements that organizations use to help them decide if they should pursue specific opportunities, a set of principles like these could help the internals@ have the debates once, in abstract, and then apply those principles to evaluate future RFCs? If course really cut down on ongoing contentious debate. I would create an RFC like that but AFAIK I have not developed enough clout here thus far so it would have to be from someone already well respected. -Mike P.S. You argument against compromises ironically soundsvery similar to the argument that leaving certain syntax in PHP encourages people to use it, and thus write "bad" code. Do you not see the similarities?
