See the problem? Really, there are a few ways this can go wrong. To a quick glance, the only clue that line 14 (“interpolate a comma”) is part of a conditional is its indentation. The indentation is important to a human reader — but absolutely irrelevant to the PHP interpreter, which simply treats the next line after the conditional as the conditional’s block. Regardless of how it’s indented, and regardless of what else is around.

The way it looks to a human is not the way it looks to the machine.

What happens if someone wants to add some logging? What if they add it after the comma line?

Now the log claims the code has added a comma, even when it hasn’t. But still, it could be worse! What if you decided to add your logging before the other line?

Now it adds a comma no matter what — even the first time through the loop, when the string is empty. So instead of a string like '123,124,125', $itemId will now have a leading comma: ',123,124,125'. Since this value is getting stitched into a SQL query later on, it means your app will blow up with a SQL syntax error.

This is why Python makes whitespace significant to program flow. The way the indentation makes it look like the logical structure is, is how the structure actually is.

And this is also why Perl — of all languages, one that normally errs on the side of letting you leave out anything that can be inferred from context — Perl insists in its syntax documentation that in cases like this, “the curly brackets are required — no dangling statements allowed.” (It then says, in typically Perlish fashion: “If you want to write conditionals without curly brackets there are several other ways to do it.”)

If you’re working in one of those languages that lets you omit curly braces around a single-statement conditional — DON’T DO IT! The potential maintenance and debugging problems are not worth the fun of saving two keystrokes (or just one, if you work in an editor that auto-closes your braces for you).

This would be a good time for me to mention that I have the utmost respect for QA people. They deal with all sorts of minutiae that I am really glad not to have to handle, and I’m really glad they’re around. That said, I am not a QA person… and so I occasionally miss the sorts of stuff they’d catch.

1. It turns out Hummingbird depends on the CLI version of PHP, and the CGI version will not suffice. This requirement is now listed in the appropriate section of the Hummingbird page.
2. Not all PHP installations have output buffering turned on by default. The latest version of Hummingbird takes account for this.
3. Various problems that can occur with the data cache file are also now reported more gracefully.

Again, my thanks to Tom Clift for some very useful patches!

You can get the latest version of Hummingbird from the Hummingbird page on my site.

So I decided to get it cleaned up and make a real, distributable software package out of it. That took a few days, especially when I started banging on it, and trying to ensure that it had a prayer of working on anyone else’s server. Plus there was the time involved for writing the docs.

But now that all of that stuff is done, I am pleased to announce: Hummingbird. A lightweight, pretty, and compact gizmo for displaying your latest tweets on a blog or other PHP-powered web page.

* And if you don’t read Coyote Tracks… what the heck is wrong with you? *g*

root@finrod:~# pecl install pecl_http
pecl/pecl_http can optionally use PHP extension "iconv"
downloading pecl_http-1.6.3.tar ...
Starting to download pecl_http-1.6.3.tar (Unknown size)
................................................................................
................................................................................
.........................................done: 1,015,808 bytes
71 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
ERROR: `phpize' failed
root@finrod:~#

The error is actually caused by a bug in PHP itself (filed in PHP’s bug database as of 2004, and currently marked “Won’t fix”): If your installation of PHP was compiled with the --enable-sigchild flag on, then the return value from a pclose() call can’t be trusted. One of PEAR’s components, called PEAR::Builder, uses pclose() as part of the package installation process, to try to determine whether a given operation succeeded or not.

Even though the operation succeeds, pclose() returns -1, signaling a failure, and the rest of PEAR then takes pclose() at its word.

Is This Affecting Your Installation of PHP and PEAR?

If you’ve gotten an “ERROR: `phpize’ failed” message when trying to run a “pecl install” or “pear install” command, try running phpinfo() — if you see --enable-sigchild in the “Configure Command” section near the very top, then you’re most likely being bitten by this bug.

Potential Fixes and Workarounds

The PHP dev team recommends recompiling without the offending flag.

However, you may not be able to do that, for any of various reasons. (You may have installed from a binary package, for instance — like most people these days.) Or it may simply seem like an excessive hassle. I offer the following patch as-is, without any guarantee or support.

First, ensure that you have the latest version of PEAR::Builder. Look in your PEAR/Builder.php file — On most Linux and Unix installations, this is likely to be in /usr/lib/php/PEAR/Builder.php, or possibly /usr/local/lib/php/PEAR/Builder.php.

On Windows systems, PHP might be installed nearly anywhere, but supposing it’s in c:\php, then the file you’re looking for will be in c:\php\PEAR\PEAR\Builder.php (yes, that’s two PEARs in a row).

Check the “@version” line in the big comment block at the beginning of the file; the line you want should be around line 19 or so. If says it’s less than version 1.38 (the latest one, at the time I’m writing this post), then try upgrading. Running “pear upgrade pear” should work. Then you can install this patch file:

patch-pear-builder-1.38.txt

Download the patch file and place it somewhere on your machine. Log in and cd to the PEAR directory that contains the Builder.php file. Then run the patch command. In the following example, I’ve placed the patch file in root’s home directory:

root@finrod:~# ls
loadlin16c.txt loadlin16c.zip patch-pear-builder-1.38.txt
root@finrod:~# cd /usr/lib/php/PEAR
root@finrod:/usr/lib/php/PEAR# cp Builder.php Builder.bak.php
root@finrod:/usr/lib/php/PEAR# patch -p0 < /root/patch-pear-builder-1.38.txt
patching file Builder.php
root@finrod:/usr/lib/php/PEAR#

Naturally, if the patch file doesn’t work for some reason, or it breaks things, you can just cp the backup file back into place.

Please let me know if this patch works for you — or if it fails horribly, for that matter.

[Updated 2009-06-03: Minor edits for clarity]

Unfortunately, I’m doing this in PHP, and it’s not possible to get a class’ parent — all you can do is find the parent of an instantiated object. So, in order to chase back up the class hierarchy, I’d have to instantiate one of each object type… and that would require coming up with parameters for each one, because these aren’t the sorts of things you can just create as anonymous items with no values.

I tried creating a static getParent() method in the top-level object, but then when I do the static call on a subclass (e.g., Human::getParent(), which should return Mammal), it apparently calls Word::getParent() anyway (and that complains that it has no parent class…)

I expect I’ll be running up against more and more of PHP’s limitations in the near future, now that I’ve gotten more accustomed to concepts like functional programming, introspection, and so on.

A quick glance at the Ruby Class documentation makes it painfully obvious how easy this would be in Ruby. While native JavaScript doesn’t support such things, Prototype.js does — down at the bottom of this page, under “Special Class Properties”, it mentions the subclasses and superclass properties, and gives handy examples.

The yak-shaving odyssey that this necessitated involved upgrading my local copy of PHP (which originally came with InstantRails) from 4.whatever to 5.2.8, so that I could develop PHP5 code at all, then installing PEAR so that I could use it to get PHPUnit, and also resolving the weird extension-loading bugs on PHP for Windows (for example, you have to load php_mbstring.dll before php_exif.dll, or else both of them will fail and complain. Ditto with php_pdo.dll and php_sqlite.dll. None of this is documented in the manual; you have to Google on it and get links to the bug database. Joy.)

But I can now run PHPUnit test on the stuff that I’m working on, locally rather than remotely. So… now can I get some code written?