8 comments
Comment from: php.dead [Visitor]
php.dead

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.

06/22/07 @ 14:46
Comment from: Larry Garfield [Visitor]
Larry Garfield

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.)

06/23/07 @ 07:20
Comment from: [Member]

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?

06/23/07 @ 14:33
Comment from: Larry Garfield [Visitor]
Larry Garfield

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.

06/23/07 @ 21:34
Comment from: [Member]

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 :(

06/23/07 @ 21:52
Comment from: Rick [Visitor]
Rick

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 = On

Ta-da! End of your problems.

07/11/07 @ 00:22
Comment from: larry [Visitor]
larry

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.

10/17/07 @ 14:18
Comment from: kavitha [Visitor]
kavitha

what is the relation between zend engine and parser in php

02/09/09 @ 21:44


Form is loading...