Matt takes issue with the push for PHP 5. He makes the point that PHP 5 offers no real advantages over PHP 4. I won’t argue with that, but I can’t resist suggesting some things that could have offered a compelling reason for developers to upgrade, had they been implemented in PHP 5, 6, or whatever:

Namespaces

It’s 2007 and we’re still stuck with one enormous big list of functions in a single global namespace. A typical production PHP installation on a shared web server has 1000-4000 built-in functions in the global namespace, many with inconsistent or contradictory naming conventions (count_chars vs str_word_count vs strlen, for example).

This could have been fixed in a relatively simple manner: just prefix each function name with its module name, much like python does – so we’d have array.walk() instead of array_walk(). Forget objects and instances, just a simple prefix (basically, treat modules like singleton objects, automatically instantiated by PHP). To preserve backwards compatibility, offer an amnesty mode that permits global function names to be used for functions that existed in previous versions.

Instead, PHP seems to be heading down the overly verbose OO route led by C++ and Java, creating modules based around classes – with the class names themselves, of course, in a global namespace.

Named function parameters

When you’re developing an API, and growing it over time, it’s common to wind up with functions with several optional parameters:

input_text($name, $value='', $css_id='', $css_class='', $size=25, $maxlength='', $tabindex='');

Trouble is, what if I’m only interested in the last paramater? I could write a function call like this:

echo input_text('first_name', '', '', '', '', '', 3);

But that’s not readable – how is anyone expected to know what that means without referring to the function prototype and carefully counting its parameters?

I could solve the problem by passing in the optional arguments as an associative array, but that’s an overly verbose syntax that requires additional error checking code. I could do it with a class, using explicit properties or methods to represent each parameter, but that’s even more verbose and less friendly.

Again, PHP could follow Python’s lead and offer named parameters, allowing a syntax something like this:

echo input_text('first_name', tabindex=3);

Hide PEAR and PECL

The reason for PHP’s runaway success is (clearly!) not its elegance as a language. It’s that PHP has the necessary critical mass of built-in library features and capabilities, all ready to use with a minimum of overhead and fuss, and all documented in one place. Developers can rely on dozens of useful extension modules being available by default on almost any PHP capable server.

When publishing a PHP 4 application, I don’t have to list dozens of module dependencies in the release notes or installation instructions. I just make sure I write my application using the standard extensions that are available by default, and it’ll run anywhere, without requiring the user to hunt down and install a bunch of modules. This is the main reason PHP has succeeded as the language of choice for web applications that are released to the public, where (for example) Perl and Java are more commonly and increasingly limited to in-house applications¹.

Since around the time of PHP 5 however, many PHP modules are gradually shifting out of the core into PECL or PEAR. In some cases this makes sense (did we really need Cybercash or IRC in the core library). But in other cases, we’re starting to see fragmentation and duplication of the core platform that is the very reason for PHP’s success.

We don’t need five different and incompatible date/time interfaces. We don’t need essential capabilites squirreled away in PEAR or PECL with documentation that may or may not be complete or useful. We need a stable, core platform of modules that are installed by default, maintained and tested together as a system, and documented in one place.

I’m not saying PEAR and PECL shouldn’t exist. But if they must incorporate parts of the core PHP platofrm, it should be as an internal method of organizing and maintaining that library; not as something that should normally be exposed to users. I shouldn’t have to say to users, “this application requires PEAR:foo v0.7+ and PECL:bar v1.3-1.7”. It should be sufficient for me to say, “this application requires PHP 5”.

Abstract the operating system and server environment

In 2007, I shouldn’t have to write conditional code that’s dependent on the operating system (if (is_windows() ... else ...). Nor should I have to write code to get around the unpredictable and often undocumented differences in the way $_SERVER is populated on Apache, IIS, Lighttpd and so on. That’s the sort of thing that can and should be done in a core library – not repeated in each and every PHP application.

Design a helpful OO system

Classes and objects were improved in PHP 5 – if your measuring stick is C++. But even PHP 5’s class-object design has some serious deficiencies, enough that object oriented PHP code typically offers no real benefits over a funcitonal design, and several clear disadvantages (most obviously, a significant overhead in the amount and complexity of typical application code).

Had the new OO design taken advantage of some of the features of a late-binding scripting language like PHP, rather than merely mimicking C++ syntax, we might have had something that actually makes it easier to write code. I’d settle for real class members and non-constant initializers. As it stands, the only distinguishing feature of a typical PHP OO application is that it’s longer and harder to read than its functional equivalent. (There are certainly times when a particular module within a PHP application lends itself to an OO design; but the cons are enough to discourage its use for all but the most naturally OO of problems).

I could go on: built-in debugging and documentation tools, official support for unit testing, fixes for brain-dead behaviour in existing libraries, lose the old-fashioned C-style preprocessor stuff, etc. What is most frustrating is that, despite all these long-standing design flaws, PHP is still the best platform for developing end-user-installable web applications. That’s quite an indictment of its alternatives.

¹ Yeah, there are many publicly released Perl and Java web apps. Just try running one on your average shared web hosting server.