On PHP and compatibility

This is a rant about PHP. PHP is one of these languages that grew out of nothing, by accretion rather than design. It shows in many places, and among them are PHP’s OOP features.

The thing is, whenever you do something with a variable – assign it to another variable, pass it into a function, return it from a function, a copy is created. This is fine for normal variables, but a huge problem for objects, because almost always you want to pass around references to the original object, and not a copy. You can override PHP’s default behaviour by putting “&” characters into various places. So when you assign an object to another variable, you do:

$a = new Foo();
$b = &$a;

When you pass objects into functions or methods, you do:

function foo(&$a) {
    …
}

And when you return objects from methods, you do:

return &$a;

This is annoying, and dangerous, because you get strange and hard-to-find bugs when you forget the “&” in one place. But you get used to it, and with a bit of discipline, everything works pretty well. Actually, most of PHP’s shortcomings can be overcome with discipline and experience. And then, it’s quite an enjoyable language, because it gives you so much bang for your brain cycle.

This rant is not about PHP’s OOP feature. It’s about a recent change in PHP 4.4. When one of my hosting providers silently upgraded from PHP 4.3.something to PHP 4.4.0 the other day, some of my scripts started to break. Well, not ‘break’ in the strictest sense, but there were dozens of lines of obscure warning messages on top of every web page generated by the scripts.

What happend was that something about this construct became illegal:

function &createFoo() {
    return &new Foo();
}

you’re apparently supposed to fiddle with the ampersands, or put them somewhere else, I’m not quite sure. Anyway, any code that does something similar breaks with the upgrade. And that’s pretty much every nontrivial PHP application in the world.

Now there are some reasons why I shouldn’t be angry with the PHP guys about this:

  • The warnings, once noticed, were easily fixed
  • The change is supposed to fix a nasty memory leakage problem in prior PHP versions
  • It probably wouldn’t have happened if I was on PHP 5 yet, which solves most of the OO issues
  • Part of the blame lies with the webhoster for doing the upgrade without researching the issues and warning their customers first
  • Part of the blame lies with me because I’ve enabled all warning messages even on a production system

But still. It’s not encouraging when your programming language silently changes semantics in a nontrivial way with a minor version upgrade, especially in an ecosystem where the developer often has no control about the version he has to use. This leaves a very bad taste with me.

This entry was posted in General. Bookmark the permalink.