As you have seen fit to criticise my article then you must surely allow me to reply. BTW, the name is Tony with a “y”, not Toni with an “i”. “Toni” is a girl’s name, and while there are many who think that I am a big girl’s blouse (or even worse) spelling my name right would be much appreciated.
Note that although my article concentrates on the RFC for the removal of PHP 4 style constructors it also mentions another RFC on scalar type hints. It is the principle of the core developers breaking the language for no good reason that I (and a huge number of others) object to. Removing existing functionality in order to fix a bug or a security issue is a good reason, but removing something simply because you don’t like it is NOT a good enough reason.
“Please do not break our language”, pleads Toni, who seems intent on using its broken features.
How are PHP constructors “broken”? What are the problems they cause? They have been in the language for 15 years and coexisted with PHP 5 constructors for over 10, and I have been using them with every PHP release up to and including 5.6.4 without an issue.
Please also note that PHP 4 style constructors have NEVER been marked as deprecated in the manual (check http://php.net/manual/en/language.oop5.decon.php for yourself) nor by the compiler, so they cannot be suddenly removed in the next release.
if you’ve kept such a codebase alive for so long, is there really a need to upgrade to PHP 7?
The need to keep abreast with the latest PHP release is highlighted in article http://blog.ircmaxell.com/2014/12/being-responsible-developer.html All those 240 million website owners out their would LOVE to keep their versions of PHP up-to-date so that they can benefit from all the bug fixes, but they can’t upgrade if it breaks their applications.
It was the volume of BC breaks which caused the slow adoption of PHP 5, and if PHP 7 continues down the path of even more unnecessary BC breaks then it’s adoption rate is liable to be even worse.
If PHP 7 cannot be used to run existing applications which run happily under PHP 5 then it does not deserve to have “PHP” in its name as it will effectively be a different language and not the same language with improvements.
The sentence “This means that code which I wrote 10 years ago should still run today, and should still run 10 years from now.” is, to me, madness – you definitely and absolutely should not expect this of ANY language across major versions.
I disagree. I have been designing and building enterprise applications for over 35 years using languages such as COBOL (16 years) and UNIFACE (10 years). In all that time both languages went through major upgrades without any BC breaks whatsoever. While new features were added the language developers took great pains to maintain all the existing features. This is because the developers who maintained the language were competent professionals who put the needs of their user community before their own personal preferences.
There are some people who say that PHP will never be anything more than a “toy” language as it will never be good enough in which to develop enterprise applications. I know for a fact that the language IS good enough as I do nothing but develop enterprise applications, but the only stumbling block is this continuous flow of unnecessary BC breaks.
Enterprise applications deal with enterprise data and not only does enterprise data have a long shelf life it is expected that the applications themselves should have a long shelf life. Developers of enterprise applications therefore expect two things from their language - stability and longevity. If PHP cannot provide these then PHP will never become an enterprise language.
I have been told by many critics that I should grow up and do what the core developers tell me to. Instead my message to the core developers is quite simple - if you want PHP to be treated as more than a language for writing toy websites then it is YOU who need to grow up. If you want PHP to be a “big boy” language then it is about time you adopted “big boy” practices and started to treat your user base with compassion instead of contempt. You can start by NOT breaking the language without VERY good reasons.