On Thu, Oct 10, 2019 at 12:11 AM Mike Schinkel <m...@newclarity.net> wrote:
> > I'm not sure where's the log jam here? > > The issue is not this specific RFC. > > As I wrote earlier, there appear to be heated and non-stop debates over > (at least) BC, and possibly other areas. People dig in on a position and > then won't consider any other options that might be available. > > > It's a logjam only if somehow we were to imagine more BC > > breaks, more deprecations and more removal of functionality is somehow > > vitally necessary for PHP - which decades of thriving without all that > > amply prove to be false. > > Let me restate then, because what was important was not that the word I > used matched internals@ circumstances exactly, but the fact that there is > an issue with how the process currently works, as many other people have > noted already. > > We can call it something other than a logjam if it is important to you > that the word matches. What about dysfunction instead? > > > I don't see what's wrong with just "do not break BC unless you > > absolutely can't avoid it"... How comes now we have to spend > > so much time at affirming the obvious? > > Frankly I would agree with that, if it were not for a large number of > people who are actively promoting changes to PHP that would break BC. So > clearly the current composition of this list includes people who see > something wrong with the approach you see no reason to question. > > Note I am not endorsing their opinion but I am recognizing they have this > opinion and they are actively trying to change PHP. So we can embrace > insanity — as Einstein would say — and fight never-ending battles on the > list, or we can find ways to accommodate everyones needs and wants, > assuming everyone else is willing to find way to accommodate the needs and > wants of people that disagree with them. > > Looking in from the outside, few people who send emails to this list > appear to be interested in finding common ground. But maybe if we help > everyone recognize that nobody wins — including themselves — when a group > of people divide up and stake out intransigent and diametrically-opposed > positions then the list can be a lot more productive. > > No single person owns PHP so it is rather ungenerous to adopt a view that > PHP should conform to any one individual view of the perfect programming > language. So what if instead we collectively ask ourselves the question > "What can I do to meet the other people half way — in ways that won't > really cost me all that much — rather than to maintain an unrelentingly > rigid posture about the needs and wants of others?" > > -Mike > > Mike - I have no issue with compromise when it makes sense. Sometimes, though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One side wants to build a 100 yard bridge to an island. The other side doesn't think we need to build the bridge because we don't need to go to the island. What's the compromise? Building a 50 yard bridge? The fact is, when there is a compromise that makes sense, people usually suggest it. One example being Zeev's proposal on the RFC to raise the error levels of undefined variables to making it opt-in. Zeev's stance on the issue was that we shouldn't do anything that was mentioned in the RFC, but, he felt that a compromise would be to at least make those changes opt-in. That proposal was rejected by pretty much everyone. That's probably why it wasn't proposed this time, either. As for this particular RFC, I think it's a pretty binary decision. Deprecate them or don't. As long as I've been involved with PHP, nothing is ever deprecated unless the eventual goal is to remove it. I could be wrong, and welcome examples where we've deprecated something where the end goal wasn't removal. Assuming I'm correct though, that provides a pretty strong reason for why we wouldn't start doing it now. -- Chase Peeler chasepee...@gmail.com
