Blogs![[Selected]](http://fplanque.com/img/down_small.gif){kind=small}
dev blog
| « Mac OS vs Windows font rendering | Ultimate daylight awareness wallpaper » |
About the PHP 5 migration chicken & egg issue
06/22/07
About the PHP 5 migration chicken & egg issue
It's been 3 years since PHP 5 has been released. Yet PHP 4 still rules on the vast majority of web hosting platforms.
This is annoying for PHP open source developers who cannot leverage the potential of PHP 5 as long as they need to support PHP 4. This is also annoying for the PHP development group since they still need to support PHP 4 instead of focusing on PHP 6.
In a way it is also annoying for the web hosts themselves, since they too need to deal with clients who want PHP4 compatibility and others who want PHP5 features.
What strikes me is that the solution seems obvious, and yet the PHP team fails to recognize it.
The only reason webhosting providers haven't massively upgraded to PHP 5 yet is because it would break applications running on their current client's site. It may also prevent new clients from installing well known applications (phpBB...) which may fail on PHP5.
Of course, that would not have been such an issue if PHP5 was indeed upward compatible with PHP4. But it isn't! (object references, clone keyword, etc.) So what do we do now?
Web hosts install PHP5 next to PHP4, but you need to rename your scripts to script.php5 instead of script.php ... which breaks existing URLs... so no-one uses that either.
The real simple solution would be for the PHP team to release some PHP 5.x version which would actually behave like PHP 4 (completely!) with a simple config switch. It could then be installed in place of PHP 4 without breaking anything.
Once that is done, any PHP application that is PHP5 aware would just include something like this:
PHP:
ini_set( 'compatibility', '5' ); |
and everything would be fine.
Maybe PHP5 should have 2 separate php.ini files. Maybe that ini_set() call should be required to come at the very top of the script. Maybe it should be a different function. But all in all, the solution seems so simple you have to wonder why anyone would want to support the older version for 3 years instead...
8 comments
The PHP development team is why we abandoned PHP and Zend. It was easier to retrain our developers on Python (currently using Django) than continue to support the asinine and insecure developments within PHP.That and 95% of PHP developers we try to hire are complete idiots. Writing a blog on your website does NOT make you a "PHP Developer". It makes you a hobbyist.
Python, Ruby, etc, however, have a much steeper learning curve for most and it takes dedication to write things in it and write them correctly, so we get much higher quality programmers by selecting a slightly less-used language.
Actually the "asinine and insecure developments within PHP" is exactly the reason to move to PHP 5.2. Between PDO with prepared statements and the filter extension, most of the "low hanging n00b" security holes (eg, SQL injection) are reasonably well handled. Anything more significant like XSRF has to be handled at the application level regardless of your language. (I won't comment on the "make it a hard language so that only l33t coders can use it" argument...)However, Francois, what you propose is completely impossible and already implemented. :-) The Zend engine (PHP 4) and Zend Engine 2 (PHP 5) are completely different. The only way to have a single engine that supported both versions would be to simply bundle both in the same binary and then only use one of them, which would be a performance disaster.
However, the PHP dev team has said for years that it is possible to run PHP 4 and PHP 5 side by side by having one as a cgi and one as mod_php. Then you only need add ~2 lines of Apache config to a .htaccess file to switch which one is used for .php files. Some major web hosts already support that (e.g., Pair.com, which is in the process of switching from mod_php4 and PHP 5 cgi to mod_php5 and PHP 4 cgi).
Implementing it directly in the engine would be a maintenance nightmare, as well as have poor forward compatibility. What about when PHP 6 comes out? Ship 3 engines in one? Of course not. :-)
What you're suggesting already exists. That it's not widely used, I'd argue, shows that it is ineffective. (And really, the compatibility differences between 4.4 and 5.2 are not as big as a lot of people claim.)
Oh no Larry, it does *not* already exist!My point is precisely that what prevents migration is that there is no standard way to throw .php files on a hosting account and then have them executed in either php4 or php5 mode.
The apache way requires to modify a .htaccess file in a manner that you can hardly automate and guarantee to work on any hosting platform.
Finally, no matter how completely different the PHP4 and 5 engines are, you say it yourself: "the compatibility differences between 4.4 and 5.2 are not as big as a lot of people claim" so why not have the same engine handle both modes?
I mean the syntactic differences. Objects pass by reference. A few functions are stricter about their parameters (eg, array_merge() insists on two arrays instead of allowing array and string, which is trivial to fix). There's a few more reserved keywords (eg, implements) that you now can't use as a constant name. Really, it's nothing earth-shattering. Everything else is new functionality that was added to PHP 5 that naturally can't be a change in something if it didn't exist in PHP 4. (Eg, array_combine() didn't change because it didn't exist in PHP 4 in the first place.) The PHP dev team actually make a considerable effort to not make PHP 5 a completely new language for the developer. Writing code that runs in both is, in my experience, not that difficult.Under the hood, however, there are huge differences. The engine was completely rewritten to handle objects as objects rather than objects as fancy arrays. Throwing in both object semantics would be impossible. It would also absolutely have to happen in .htaccess anyway (or php.ini), because PHP 4 and later is JIT compiled. ini_set() calls don't get called until after the whole file has been compiled. You can't change how to interpret the compilation after the compilation. :-)
So you'd be modifying .htaccess anyway. See here for example: http://forums.asmallorange.com/index.php?showtopic=7775
Besides, the PHP dev team is not interested in doing anything with PHP 4 anymore. All of their work is going into PHP 6 and Unicode. What you're proposing will, I will wager money, never be added to the language. And even if it were, it would be added in PHP 5.3 at the earliest, which is still not near release. That would still be useless to PHP adoption for another year or two, by which point we'd be on the edge of PHP 6 anyway.
JIT issue: you don't even need to be creative to find a solution here:#! php5
at the top of the file. That has to be something the JIT compiler can read...
It really isn't anything else than a goodwill issue on the PHP Team. Yes I agree... it's likely to never be done :(
The only incompatibilities i experienced when switching to PHP 5 were related to the expat parser and a default setting that changed. The rest was in the ini_file, where we use the zend.ze1_compatibility_mode = OnTa-da! End of your problems.
not true.. we have some php files that don't work at all in php 5.. and none of the issues above are causing the problem.. rather than spend weeks rewritting ... it is much easier to go back to php 4. 
what is the relation between zend engine and parser in php This post has 1 feedback awaiting moderation...
Comment feed for this post
