If you’ve been paying attention to the PHP scene then you should be aware that the next significant revision — version 5.2 — is imminent. Or at least, it should be. Of course this is PHP so no new release can be made without at least a bit of drama.
It seems that this time around, there are a few issues generating controversy on the php.internals mailing list (please note: this is still under discussion so might change before release)…
First up, some tightening of the rules for object-oriented code means that methods declared as both static and abstract will now cause an E_STRICT error. It seems like a minor point to me — what would a static abstract method do anyway? — but some seem to feel it could cause widespread backwards-compatibility problems.
Second there’s a change in the behaviour of the mktime() function: calling it with no parameters will throw an E_STRICT error. It’s has been noted that calling mktime() with no parameters (or all zeroes) is equivalent (if slower) to calling time(), so one wonders why anyone would bother.
Finally, and more seriously from my point of view, is a reference to the filtering (against malicious code injection) of the entries in the $_SERVER array. The dispute itself is a fairly minor one — it seems that in PHP5.2, the array will be filtered automatically only for servers running Apache 1.x. Others will be enabled in later releases. The reason I find this alarming is that it raised an issue of which I wasn’t fully aware — namely, that certain fields in the $_SERVER array cannot necessarily be trusted. I guess I had heard about this before but the potential severity hadn’t really dawned on me. If this issue concerns you, here are some blog entries that might shed some more light.
On a final note, one feature of PHP5.2 that I’m sure many people will latch onto is the new uploadprogress_get_info() function, which (as the name suggests) allows you to track the progress of uploaded files. So with a bit of Ajax-y magic you could create a real-time upload progress meter, which is great for large files. We currently use some homebrew C code to achieve the same thing, but it’ll be nice to be able to ditch that and use native PHP calls instead. You’ll find a little bit of info on the new functionality here. For more accurate info on this subject, check out this post.