20
Jul 07

Xdebug 2.0 released

Hmmm. First PHP application programmers start GoPHP5.org, then the php core team announces the EOL for PHP4, then namespaces get added into PHP6, and now Xdebug 2.0 is finally released. It’s not quite the precambrian, but it’s definitely been a busy few days!

Xdebug, for those of you who prefer to debug PHP code using echo and var_dump(), is a bloody lovely zend extension for php that lets you get proper debugging information for when stuff goes pear-shaped (excuse the pun). From the official announcement:

It is finally here, Xdebug 2.0.0 has arrived! After about four years of work I finally found it ready to release. Have fun! After almost four years of work, Xdebug 2 is finally ready. With improved functionality and many new features it is ready to totally change the way you develop in PHP. Some of the new features and updates include improved stack traces, execution traces to files, code coverage analysis and much improved remote debugging support. Xdebug’s documentation has also been rewritten for more clarity.

I’m leaving it for Monday to install at work, but I’m going to check the installation goes okay at home over the weekend. Finally getting function traces without having to call PEAR::Log every five microseconds? Yes please! And nicely timed just before a bout of dev work in the office too

.


16
Jul 07

More on PHP5 adoption

Matthew Mullenweg isn’t terribly impressed with GoPHP5 or the php-internals people on the whole topic of dropping PHP4 and moving on to PHP5 and PHP6. Now, given that Matt’s the guy who founded WordPress, I reckon his opinion’s worth listening to, and given how much time I spend using vim, LaTeX and mutt, I know where he’s coming from; but he’s wrong in this instance, or at least, he’s looking at it the wrong way.

See, the difference between PHP4 and apps like LaTeX or vim is that, well, LaTeX is done. As in, it works, it’s bug-free (no, seriously, it’s as bug-free as it gets outside NASA, and a bit more so on occasion), and it does everything that its users require it to do, and well. PHP4… doesn’t. Yes, you can build apps with it, and yes, many great ones have been written. Cool. But it’s object model is fundamentally … not an object model. And it’s slower than PHP5. And if PHP itself is to survive as a language in what is a competitive space, it has a lot of work that needs doing to it. Fundamentally, it’s not done yet. It’s getting better – but to do that, it has to change, and if that means PHP4 is being left behind, I don’t think that’s worth any more tears than, say, Debian 3.0 being left behind when Debian 4.0 replaces Debian 3.1 as the stable release. It’s just how this stuff works.

Vidyut on the other hand, agrees with Matt, but more from the point of view of the end users, rather than the developers. And that’s not really all that on point, to be honest. If the developer does his or her job well, then the end user should never know what the engine is doing in the background – which, ironically enough, is his first reason as to why the PHP4->PHP5 move is a bad idea. I don’t quite get that reasoning myself. As to saying that the code clean-up that PHP5 permits is completely pointless… well, that’s just plain silly really. I mean, you can’t say that the end users shouldn’t know what the engine is doing on one hand, and on the other say that they think your code is fast and clean.

Maybe it’s a confusion over who the end users are. I mean, from the php-internals point of view, app developers are the end user; and from the developer’s point of view, the end users are, well, users.

This whole idea, though, of forking off PHP5 and leaving PHP4 alone… well, in effect, that’s what’s being done. PHP4 is being dropped. So, if you want to maintain it, do what the Joomla core team did, take a snapshot of the code and start with your maintenance and release cycles and keep PHP4 going.

I don’t think it’s a good idea though. I’ve coded in PHP5 and in PHP4, and I’ll never code in PHP4 again if I have any degree of choice in the matter. It’s too difficult to properly implement and maintain designs in it when the number of developers rises above one!


13
Jul 07

PHP4 End of Life

Got to hand it to the internals people, when an idea’s a good one, they run with it. First the announcement that namespaces are now officially a part of the development trunk for PHP, then this:

PHP 4 end of life announcement
[13-Jul-2007]

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

So we will finally see adoption rates for PHP5 climb a bit. You have to wonder – will the lessons learnt here prevent the PHP4-5 problems during the PHP5-6 cycle?