The problems have been named in the internals list, and have been, in part, mentioned in your article.
The so-called problem with traits and namespaces is that they completely ignored PHP 4 constructors in the first place, which is the fault of the developers who implemented those changes.
The problem of “accidentally” creating a method with the same name as the class and thereby “accidentally” creating an unwanted constructor is purely the developers fault. Those of us who have been around long enough to know what we’re doing would not make such a newbie mistake. This is a developer error, not a language error.
The problem with a subclass not knowing the name of the parent constructor, of if even one exists, will be solved by https://wiki.php.net/rfc/default_ctor if it were extended to deal with both styles of currently valid constructor.
I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?
There are over 240 million websites out there running PHP. Unless you are prepared to run an audit on every one you cannot say for certain that any piece of functionality is not being used. It has already been stated that significant portions of the PEAR library still use PHP 4 constructors, and there must still be a significant number of applications out there which were developed using PHP 4. If the PHP 4 constructors have never been marked as deprecated then their developers had absolutely no idea, no warning that their code needed changing.
There is a rule that nothing can be removed from the language without it being marked as deprecated first, and PHP 4 constructors have never been marked as deprecated. As the next major release as 5.6 will be 7 (the need for 5.7 was voted down) it will therefore not be possible to remove them in 7.
And what is the status of these languages today?
You don’t understand the difference between deliberately moving to a new language and updating the existing language. My company moved from COBOL to UNIFACE because the market for new COBOL applications for the HP3000 dried up. UNIFACE provided the ability to develop applications which could run on a variety of platforms with shorter development times. The original version was for the desktop only but a later version also provided the ability to access applications via a web interface. Despite the numerous upgrades to the language there were never any BC breaks whatever ran in the current version would always run in the new version.
I decided that web applications were the way of the future, and that UNIFACES’s ability to develop web applications was too clunky for my taste. As the language could never be modified to meet my expectations I decided to switch to a language that was designed specifically for the web, not one with a web add-on. That is when I discovered PHP, and after proving to myself that it could do what I wanted I stuck with it, and I am still with it after 14 years.
Updates to a language, such as new features and bug fixes, are perfectly OK, but BC breaks are not. It is one thing to move to a new language because the old one doesn’t do what you want, but it is another thing entirely to change the language into something else and completely destroy the old language. Any new version of PHP which is incapable of running EVERY existing application that runs under the latest version of PHP 5 does not deserve to use the name “PHP” as it will effectively be a new language instead of the old language with new features.
On a final note - I’d like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort?
It’s not the effort, it is the principle. The idea that the core developers can remove long-standing functionality from the language FOR NO GOOD REASON and thereby break existing applications is wrong. It destroys confidence in the language. The core developers should learn to be more considerate to the millions of developers who use the language and less selfish in trying to force their personal preferences on the entire community.