New features

PHP 5.3 includes a lot of new features. Some of them are new language features like namespaces, closures, exceptions chaining, jump labels etc., and even though these are very recommended to learn, they are not required. You can continue to write code as you are used to and chances are that it will still work (more about that in Legacy code).

What is important from new features is fixes are enhancements. For example new garbage collector and other fixes reduce memory usage and increases performance. There are also some new extensions like phar, sqlite3 and fileinfo and some libraries (like mysql or openssl) have some major improvements. Finally, Windows support is improved even further and now is expected to be even more production-ready.

Legacy code

Apparently the biggest problem is with legacy applications – somehow everyone just decided that because of all these new features, everything should break. If you’d look at backward incompatibility list here, you notice that not that much has changed. Or in other words – if your code was “correct” before upgrade, it will work fine with PHP 5.3 too. For example static and/or private setters, ereg and some more other features shouldn’t have been used in a first place as manual clearly stated that.

Personally I have upgraded around 10 projects to run on PHP 5.3, each took less than an hour. On my development machine I also have strict error reporting level so I even had to remove marked-as-deprecated code, but for larger part of code everything worked fine. Furthermore, some of that code has been written using PHP 4, a couple years ago, and it still worked just fine.

Debian…

As far as I’m aware of, main linux distros like Debian or Red Hat do not have PHP 5.3 in their stable repositories, which makes upgrading potentially very hard or impossible. I have come across this before – sysadmins do not want to install anything outside from stable, so the only option is to wait (that happened to me when PHP 5 was still not well adopted). This is probably the only reasonable argument to not switch to PHP 5.3, but only if you don’t have option to switch servers.

I’m lucky with this problem, because I do not administer servers, but still can request for any PHP version I want. If you do not have this option, maybe it’s time to switch hosting server provider? There can be different situations, but software version shouldn’t be a limiting factor, especially when new version is available and known to be stable enough. You can even use multiple PHP versions if switching server would require testing a lot of applications.

Why you should be using PHP 5.3 right now

Firstly because it has those new features, which mean that you can start to use them as an early adopter and benefit later. All second iteration frameworks (Zend Framework 2.0, Symfony 2.0, Lithium etc.) coming out late this year will use PHP 5.3 extensively, so knowing how namespaces work (I’d say they are the ones you need to look first) and how to utilize closures will mean that you can get going very quickly.

Doctrine 2.0 is probably the best example of why you should learn PHP 5.3 now – most of its features could be written in older versions too, but not as clean and easy to understand. And it’s already in alpha stage, so stable version might be coming out very soon and yet again – if you want to stay on top of your game, you need to know how it works and how to leverage all new features.

As mentioned above, because of new garbage collector implementation PHP 5.3 performs much better (benchmarks). From my personal tests I have noticed that Zend Framework uses much less memory, just because there is less memory leaks, Doctrine of course gets a big speed up too.

Conclusion

I’m yet unsure what is all that buzz about – PHP 5.3 is stable, way faster than previous versions and works with legacy code just fine. Considering that it has new core features, which will be expected from developers to be known in just a few months, I don’t see a reason why you shouldn’t use it. And if you have any questions you can just ask me directly on twitter.

I have been using Zend Framework for some time now, and found that only possible way to use XmlRpc Server package is to delete all functions signatures checking. My production server has Zend Optimizer installed and it just breaks Reflection functionality.

For tests I created simple reflection example:

/**
 *  My Class
 */
class test { }
 
$oClassReflect = new ReflectionClass("Test");
print $oClassReflect->getDocComment();

First time script outputs:

/**
 *  My Class
 */

Next times there is no output at all – all comments are gone (in Optimizer’s cache). I still can get methods of class (source code is not gone), but I cannot use comments to mark params/return types and later use them to validate I/O.

I don’t know yet if it’s a problem with my production server, but Zend manuals are not very clear and I can’t find any information about comments stripping issue. Has anyone had similar problems?