“A nearly impenetrable thicket of geekitude…”

The Javafication of PHP

I do a fair amount of programming in PHP, but I’ve never been an uncritical fan of the language. My initial impression of it was that PHP must be the secret love child of Kernighan & Ritchie era C and Perl 4, combining as it does a pre-C++ model of object oriented programming with dynamic typing, a general attitude of “if you write it, I’ll find a way to make it mean something” and a library that only the kindest could regard as other than rambling and incoherent.

Of course, this characterisation is unfair to all parties concerned: if you understand the design goals of the three languages, you can see that their designers hit the intended targets. This is backed up by the observation that all of them have been extremely popular; a survey recently found PHP available on more than 13 million domains, on 1.3 million IP addresses.

The problem arises when the usage of a language grows out from the original problem domain; as its usage grows, a language needs to develop in order to avoid being overtaken by something more suitable. In the case of PHP, the original design was fine for relatively small projects involving a few dynamic web pages (and it’s hard to find something simpler to use for that kind of project) but it doesn’t really scale up. My major complaints have always been that PHP lacked the facilities, and to an extent the attitude, you need in a language for writing large, robust systems: ways to tell the compiler what you mean so that it can check things for you, ways to hide data in one part of the system from other parts, and so on. These are the sorts of things that K&R C (as ANSI C and C++) and Perl 4 (as Perl 5) acquired as they matured.

You might say that I’d prefer PHP to be more like Java, and that’s probably a fair summary as Java is my preferred language for most things these days. Certainly, if I’m thinking about extensions to an existing PHP system, the choice is definitely between “more PHP”, “do it again from scratch in Java” and “try and blend the two”.

A couple of recent developments have given me some hope that changes from both the PHP and Java ends of the problem might make that kind of choice a lot easier in the relatively near future. The first item came in an announcement at the JavaOne conference back in June, where in the Technical General Session Graham Hamilton averred [URL removed 20051030: video no longer available.] that “scripting languages are our friends” and that JSR 223 had been launched to standardise the integration of scripting languages with Java web containers. The reference implementation will involve Zend implementing PHP into Tomcat, the reference (and most popular) web container.

Sun clearly believe that PHP and Java will fit together well, and hope that Java can become the natural “upgrade path” for PHP developers who find that their projects have outgrown PHP. A cynic would reply that “they would say that, wouldn’t they” but I am inclined to agree with Sun, and I wish this effort well if for no other reason that having any clear upgrade path from PHP other than reimplementation in another language has to be a good thing. The indications are that this may take a year or so to come to fruition.

If the JSR 223 work looks like bridging the PHP and Java worlds in cases where PHP runs out of steam, version 5 of PHP looks like extending the capabilities of PHP itself in very much the kind of way I’d like. An excellent recent article by Henry Fuecks at Sitepoint summarises the changes. For me, the most interesting ones are:

  • Objects now passed by reference, not by value.
  • Protected, private and public class members.
  • Const, static and final class members.
  • Abstract classes and methods.
  • Interfaces.
  • Java-like exceptions and try-catch syntax.
  • (Limited, optional) argument type-checking.

All of the above are recognisable as “just like Java”. They don’t make PHP into Java; that isn’t the intention. They do make it possible for a disciplined developer to write PHP that is a lot more robust: more explicit, more maintainable and less prone to bugs.

Given a degree of natural caution in the use of new major software versions in production systems, it could be that PHP 5 and JSR 223 are both ready for use around the same time. I’m looking forward to it.