On Thu, 12 Sep 2019 at 19:10, Lynn <kja...@gmail.com> wrote: > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's important to consider the impact of a change, > including for the Wordpress community. However, I think most people agree > that the quality of Wordpress code and Plugins is highly debatable. I don't > like the idea of not being able to progress because Wordpress users won't > upgrade PHP. >
This raises an interesting, tangential point. Who is PHP for? One can argue that WordPress, with it powering 34% of the web (source: wordpress.org) represents more than 50% of PHP users, and therefore aligning the language to how they use it would be sensible, as they are the majority of users. PHP and WordPress have had a symbiotic relationship, the success of one increasing the success of the other. Those who wish PHP was more advanced and different (and I count myself amongst them) do well to remember that PHP has become extraordinarily successful in spite of the flaws now perceived. It's a good language that fills a niche even server-side JavaScript hasn't usurped. There is no shame in a language staying true to its roots, plateauing and eventually dying a death (cf Perl 5). I don't want that, but it's a valid route. And the communities that use PHP in a way many on this list look down on will be thankful to continue to have a language they can use, can hack with, and get stuff done. Even if there's a few extra bugs. The rest of us, meanwhile, have the opportunity to use a programming language that's closer to whatever we feel is a "proper" language (a vibe I pick up in the "they look down on us" and "I'd rather PHP was more like X" messages). If you're going to have to justify upgrading your code, why not propose a rewrite in another language? One can sell it on the fact it won't have the flaws regularly brought up on this list - like warnings instead of exceptions, or two opening tags. Or, despite the fuss on-list, do those who decide how the next project will be written/the current one rewritten, not care to the same extent, and other factors will influence their choice? Personally I cannot wait for new features to be added, but feel our heritage is as important as the future. Jordi expresses my feelings, and I quote him: Breaking BC here does not seem to bring much. If there are cases where > enforcing strictness might allow better JIT for example, then I could > see the case being made. But simply turning working code into fatally > failing code isn't progress. [...] So what do we gain exactly? > Peter
