Legacy code
Some people have this misconception that there is a plot to kill of the original mysql extension (aka ext/mysql) in PHP.
So first off, I know that bloggers are not journalist. So apprently fact-checking is not required for a rant blog post. ;-) But if a blog post is a rant, it should be labeled as such.
Improved
ext/mysqli (hint: "i" as in improved) has been the goto extension for years. If anyone writes code in 2011 which uses ext/mysql, then they should be fired or demoted to trainee. MySQL's 4.1.3 beta was released in 2004 and ever since its release, it's been "strongly" suggested to use ext/mysqli.
PHP's fault in this case is that it didn't drop ext/mysql sooner.
Legacy code
The problem with legacy code is that it's usually not a legacy with the good meaning of the word.
It's indeed a legacy of the past which often exhibits all things that can go wrong on a PHP project.
In a situation where a project requires an older version of PHP to run, there are two kind of improvements developers (and essentially the companies employing them) miss out on: active and passive.
Passive improvements
… generally happen and don't require anyone to re-write any code, examples include:
- PHP's runtime became more efficient
- improvements such as garbage collection
- most importantly: bugs were fixed
Active improvements
… may require updates to the code base — they mostly include new features (e.g. through a new extension) or extensions of the language itself — namespaces, traits, etc..
Ecosystem
In addition to missing out on the improvements of the language another major problem is that since the code base requires an out-dated (maybe vulnerable) version of PHP to run, companies are often stuck in an entirely outdated ecosystem.
From top to bottom: it starts from the OS (Security updates?) — Linux, but also includes the services you run — MySQL and Apache. But there you go, the entire LAMP stack is fubar'd.
Anyone could argue that it's possible to e.g. run PHP4 on a recent Linux with semi-recent components, but let alone compiling PHP and/or backporting patches for security issues and crucial bugfixes don't make maintainance exactly trivial.
Waste of …?
The real problem is not that companies waste resources to update their code base, the problem is that they waste resources to maintain a status quo.
Of course there are many excuses why an update is not possible: it probably starts with a lot of managers who have no idea how to plan a software project. They end up with a pile of spaghetti code which works but nobody is able to update it because it might break.
In the end it turns out not be a technical problem, but a social problem. Or a question of skill level.
PHP
The debate errupting whenever changes to PHP are proposed is hilarious. They are not even so fundamental to begin with.
The plan here is to deprecate (!), but not to remove an extension with well known alternatives (ext/mysqli and ext/PDO) available.
To avoid these discussions today it would be helpful, if some sort of rule is established that in the future an extension is deprecated right away when an alternative is included (not sure if this is covered by the new release process RFC). Especially when the upgrade path is as trivial as in this case.
Drop, drop, drop
And after an extension has been deprecated for X months, it should dropped from core and moved to PECL.
People would still be able to install it and if anyone wants to take up the development because they think that writing c-code is easier than updating a PHP application from ext/mysql to ext/mysqli, then there are of course welcome to do it.
It's also an opportunity for companies to come in and help maintain an extension. Then again, I really don't see the advantages of this when an update is possible. But to each their own.
In the end, removing an extension from core takes off the burdon from the core developers. It allows them to focus on current extensions and language features. It allows them to enhance the language versus maintaining dead code for people who don't want to update.
Fin
I think it boils down to really embracing new releases.
I think it's very reasonable for anyone and any company to update a code base on a three year cycle to keep up with PHP releases. If that's currently not possible for your legacy code, then it's time re-think the way you're developing.
Also, check your facts and don't spread FUD.
Trackbacks
No Trackbacks
The author does not allow comments to this entry
Comments