$arr[null] = "Null string";
$arr[false] = "False string";
$arr[0] = "Zero string";
 
print_r($arr);

It’s…

Array ( [] => Null string [0] => Zero string )

Surprise!

It gets better:

$arr[null] = "Null string";
$arr[false] = "False string";
$arr[0] = "Zero string";
$arr[''] = "Empty string string";

gives

Array ( [] => Empty string string [0] => Zero string )

Hat tip to Will for this one.

The initial implementation simply took a string and looked it up in the interpeter’s global function table, then invoked it:

1
2
3
4
5
6
7
8
9

<?php
 
function add($x, $y) {
    return $x + $y;
}
 
$f = "add";
print $f(1, 2); /* Prints 3 */
?>

This probably got implemented in a couple of hours while Rasmus or one of his minions debated how it should work on IRC, and it shows:

• Because a “function” variable is any arbitrary string, there’s no way to statically validate them. Static analysis of PHP is a crap-shoot anyways, so this isn’t a big loss on its own, but overloading one type (string) to do something magic introduces more chances for programmer confusion, too.
• Attempting to call an undefined function is a fatal error, as it should be. However, since it’s trivial to create a “function” variable that refers to an undefined function, this is a lot more headache-inducing than it needs to be. The presence of function_exists doesn’t help; it just makes generic code that much more verbose.
• There are multiple code paths that result in a string being evaluated as a function name, and they don’t all have the same semantics. call_user_func doesn’t abort your script if you pass it a bogus name, but you can’t tell if the called function might return FALSE, you’ll never know it because call_user_func returns that value to indicate errors.
• Several early examples of how to use this feature showcased scripts that accepted function names straight out of user input, which is a security disaster on par with arbitrary code injection. Just because you only created HTML fields for certain names doesn’t mean malicious or bored users won’t start stuffing garbage in there.

Unfortunately, when PHP 4 introduced a simple object model to PHP (necessitating a new variable type, for objects — but more on that later), the PHP team opted not to clean up this hole in the language. Instead, support for methods and static methods was bolted on top. Instead, the $variable() syntax was extended to accept arrays as well. All of the following variables might be callable:

Function names as strings.

$f = "add";

Instance methods, as an array.

$ops = new MathOperations(); $f = array($ops, "add");

Static methods, as an array.

$f = array("StaticMathOperations", "add");

Static methods, as a string.

$f = "StaticMathOperations::add";

There’s no real way of knowing if a value is callable unless you try.

PHP 5.3’s closure syntax addresses some of this: closures are handled as a resource type within the PHP interpreter, finally. However, they come with their own weird implementation limitations.

1
2
3
4
5
6
7

<?php
function monolithic_dimensions() {
    return array(1, 4, 9);
}
 
print monolithic_dimensions()[0]; // syntax error, unexpected '['
?>

Of course, it’s trivial to work around:

1
2
3
4
5
6

<?php
/* ... */
 
$temp = monolithic_dimensions();
print $temp[0]; // Prints 1
?>

In almost every other language with array-indexing syntax, any expression can be indexed if it evaluates to an array. Consider Python:

1
2
3
4

def monolithic_dimensions(): 
    return [1, 4, 9]
 
print monolithic_dimensions()[0] # Prints 1

Or Ruby:

1
2
3
4
5

def monolithic_dimensions
    return [1, 4, 9]
end
 
print monolithic_dimensions()[0] # Prints 1

Or even C:

1
2
3
4
5
6
7
8
9
10

#include <stdio.h>
 
int const *monolithic_dimensions() {
    static int const dimensions[] = {1, 4, 9};
    return dimensions;
}
 
int main() {
    printf("%d\n", monolithic_dimensions()[0]); /* Prints 1 */
}

Of course, since there’s no formal language spec for PHP, there’s no way to know whether this is by design or by accident.

Exceptions were added to PHP in PHP5, allowing blocks of PHP to terminate abruptly. Constructs like

1
2
3
4
5

<?php
$h = fopen("config.ini");
$str = some_local_function($h);
fclose($h);
?>

do not guarantee that $h gets closed reliably: if some_local_function throws an exception, flow never reaches line 4 and never closes the handle. For most things, this isn’t actually as big a deal as it would be in other languages: connections, file handles, and other resources are all closed at the end of each request anyways.

However, sometimes you care what order resources are closed in, or you want to perform some cleanup actions with a resource before closing it, and then the lack of a finally clause hurts. One PHP project I’ve worked on talks to an AMQP broker; AMQP has a defined connection teardown process that’s necessary to verify that published messages are actually being processed. The ideal way to handle that would look like:

1
2
3
4
5
6
7
8

<?php
$amqp = new AMQPConnection(/*...*/);
try {
    /* Publish messages using $amqp */
} finally {
    $amqp->close();
}
?>

Without finally (or with blocks/using statements, for the Python and C# programmers out there), the obvious solution is much uglier:

1
2
3
4
5
6
7
8
9
10

<?php
$amqp = new AMQPConnection(/*...*/);
try {
    /* Publish messages using $amqp */
} catch (Exception $e) {
    $amqp->close();
    throw $e;
}
$amqp->close();
?>

Note the near-mandatory duplication.

Of course, it’s possible to work around the lack of automatic resource management syntax by using an idiom from, of all things, C++:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php
class Closing {
    private $closeable;
    function __construct($closable) {
        $this->closeable = $closeable;
    }
 
    function __destruct() {
        $this->closeable->close();
    }
}
 
/* ... */
$amqp = new AMQPConnection(/*...*/);
{
    $close_amqp = new Closing($amqp);
    /* Publish messages using $amqp */
}
?>

However, this relies on understanding the interactions between scope, object lifespans, and PHP’s optional garbage collector, which are non-trivial.

The PHP development team doesn’t think this is a problem.