On Thu, Oct 10, 2019, 13:03 Chase Peeler <chasepee...@gmail.com> wrote:
> 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? > No. The compromise is funding a ferry system. Or laying Internet between them. Or a passenger pigeon mail route. Sometimes compromise requires deep discussion about the motivations for each side and coming to a lateral, mutually acceptable, solution. But we'd rather not discuss motivations and just bicker about the surface results. I.e., argue the X, rather than the Y, of these little XY problems we're solving. > 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. > Short tags are deprecated, per the manual. They are not planned to be removed and, per the vote discussions and margins, probably won't ever go. >