Re: [RFC] Remove PHP 4 Constructors
| From: | Tony Marston | Date: | Wed, 21 Jan 2015 14:42:37 +0000 |
| Subject: | Re: [RFC] Remove PHP 4 Constructors | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-80935@lists.php.net to get a copy of this message | ||
"Ralf Lang" wrote in message news:54BEB145.7030808@b1-systems.de...
That's precisely the point I am trying to make. Too many frivolous BC breaks cause more problems than they fix.#1 and #2 may be considered to be genuine improvements by the user community, but #3 most certainly will not. It does not matter how you try to dress it up, forcing your end users to jump through hoops before they can upgrade is a customer relations disaster.PHP and other scripting languages have done it before. They will do it again.
From time to time, major release really means some rare cases won't work as before and require manual intervention to make work again. It's not php-exclusive. Hell, even in the linux kernel, drivers and infrastructure from bottom to top we see it every day. Design changes, things break, fix or perish.Those BC breaks were necessary and not frivolous.
1995 HTML will probably not look exactly as intended when browsed with today's browsers.But at least they will still appear and not simply produce a blank page.
Chances are, even your 20 year old C or C++ code won't compile on the latest gcc without some trivial changes or some additional compile options and even if it does, it will violate some widely accepted policy. In distribution packaging, we face the latter more often than you think. This is especially true with feature-complete software dinosaurs.Trivial changes because of necessary BC breaks I can live with, but monumental changes due to frivolous BC breaks just make me mad!
Software needs maint. to keep it alive in an ever changing environment of hardware, OS, platform libraries etc. If PHP decides to drop PHP4 constructors in PHP7, which is 2 and a half major releases later,The number of releases later is irrelevant. PHP 4 constructors have NEVER been marked as deprecated, therefore they are still fully supported and not obsolete. And I still say that their removal is entirely frivolous and unnecessary.
then you can run your older PHP, you can add support via an extension or fork or you can do trivial changes to your libraries. Each has its own costs. Doing nothing also has costs.A minor cost to the core developers is far better than a major cost to the 240 million websites out there in userland.
I have to maintain some customer apps on a PHP4-based framework (version). It hasn't been fun to keep it working on PHP5.3++ and it won't be fun on PHP7 either. It's just the way it is. I think the customer will be charged a lot of support hours but he will get a much better product.How can the move from the old to the new constructors add any value to product? It certainly would not make it run faster or produce better results.
In theory, I could just run older PHP releases but in practice, I wont.I also want to be able to run the latest PHP release so that I can gain access to all those bug fixes, but a constant flow of frivolous BC breaks makes this very difficult. -- Tony Marston