First of all, Amen to Arvids Godjuks. I think managed to clearly convey the 
opinion of a majority of the PHP community.
----

Some small things I like to add. IMHO the backward-incompatible changes that 
are currently discussed aren't about radical changes, but incremental 
improvements.

There are a number of issues common in PHP applications, that you don't often 
find in programs written in other languages. Experienced PHP developers hardly 
fall for these gotchas, but the quality of PHP applications written by novice 
developers is typically lower than, for example, written in Python. This is one 
of the reasons that it's becoming harder and harder to convince people, both 
within an organization as well as developers in general, to start any new 
project in PHP. There are issues that are considered unacceptable for a modern 
language.

Requiring to fork PHP or create a new flavor is unreasonable when compared to 
other languages. C++ introduced a paradigm shift from a procedural to an 
object-oriented language. This can't be compared to the changes currently 
discussed. On the other hand, if we look at changes introduced with major 
releases in other languages, like Python, Perl, Java, EcmaScript, etc, we can 
only conclude that even the most progressive portion of the PHP community is 
still relatively conservative.

Also, the notion that we always had a strong bias for downwards compatibility 
is not completely accurate. There have been extensive backward-incompatible 
changes in the past. None of the changes proposed today come even close to the 
impact that changing the behavior and finally removing `register_globals` had.

Using a directive to apply backward-incompatible changes should not be expected 
to get a lot of support. The limited situation where this would be the case 
with `strict_operators` caused great opposition. The P++ directive proposal 
would take this, with all the downsides, to a whole nother level.

LTS versions are the tried and tested method to ensure that legacy applications 
can continue to run. This is favorable to a highly experimental method. Sure 
LTS requires some extra effort from the maintainers, but not nearly to the same 
extent that a fork or flavor would.

The real risk to the future of our language isn't related to legacy apps. A bit 
harsh, but they're vendor locked and will continue to use PHP anyway. On the 
other hand, this lack of interest in PHP by novice developers is a big problem, 
as is the diminishing number of new projects that are created in the language. 
We should prevent PHP from becoming a legacy language.

In short, please just allow PHP to progress in a natural (and slow) pace, 
rather than forcing a fork which has changed to much that switching is not 
trivial and on the other side have an original that completely stagnant.

Yours,
Arnold

[Arnold Daniels - Chat @ 
Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=3yfvn)        
[3yfvn]

On August 9, 2019 at 13:41 GMT, Zeev Suraski <z...@php.net> wrote:

Reply via email to