New Features in PHP 5.6

January 11, 2014

It’s no blasphemy saying the core devs of PHP have had some hiccups and some truly ridiculous arguments about some of the features – just look at this silly discussion on why a shorthand array syntax is bad, back from ten years ago. Arguments like these, among other things, make people think some of the core devs don’t even use PHP in their day to day lives, and are why the devs of PHP and the people using PHP are often considered unprofessional.

The future isn’t bleak, though. It’s been a while since the release of PHP 5.4, and new versions have been coming out faster and faster ever since. When 5.5 hit and introduced some unexpectedly great features, the PHP community breathed a sigh of relief and regained hope of a more dedicated, structured and smart core development. Whether or not we’ll actually get this remains to be seen, but the future does indeed look promising, especially if one looks at the PHP 5.6 changes made so far.

While a full explanation of all the upcoming updates would be far too vast to cover in one article, I would like to direct your attention at some I personally deem most important.

MIME types in the CLI web server

MIME types in PHP can be used to output content as a type other than PHP, that is, as a type other than text/html. When you run a PHP page, the default output is text/html, but you can use headers to set it as, for example, PDF and generate PDF files. When a server is aware of different MIME types, as most servers like HHVM, Apache and Nginx usually are, they know how to serve a given file by default, judging by its extension, without you having to set specific instructions in PHP itself. The command line server from PHP 5.4 had only a few MIME types so far, and this version will introduce dozens more. It’s safe to say that all the common MIME types will be covered by the built in PHP server now.

Internal Operator Overloading

This is a feature we as web developers using PHP probably won’t be exposed to, due to the keyword “internal”. Internal means “non userland” where userland is the area of PHP development we, the end users of PHP, use. It applies only to internal classes, in order to make development in that area simpler and code cleaner to read. A detailed explanation can be found here.

Uploads of over 2GB are now accepted

Until 5.6, no uploads of 2GB and over were supported in PHP. This is no longer the case, as the changelog states, and uploads of arbitrary size are now supported.

POST data memory usage decreased

POST data memory usage has been shrunk by 2 to 3 times, following two removals: the always_populate_raw_post_data setting from php.ini, and the superglobal variable $HTTP_RAW_POST_DATA. What this means is you can no longer access raw post data that way, but need to rely on a solution such as:

$postdata = file_get_contents("php://input");

Note that getting POST via ://input is unavailable when a form is multipart (in other words, when a form has a file upload element).

Improved syntax for variadic functions

Variadic functions are functions which can take an arbitrary amount of arguments. When you supplied some arguments to it, you usually had to do some splicing after calling func_get_args, which was somewhat impractical. As taken from example here, the syntax in 5.5 and earlier was:

class MySQL implements DB {
    protected $pdo;
    public function query($query) {
        $stmt = $this->pdo->prepare($query);
        $stmt->execute(array_slice(func_get_args(), 1));
        return $stmt;
    }
    // ...
}

$userData = $db->query('SELECT * FROM users WHERE id = ?', $userID)->fetch();

now, the syntax will be:

class MySQL implements DB {
    public function query($query, ...$params) {
        $stmt = $this->pdo->prepare($query);
        $stmt->execute($params);
        return $stmt;
    }
    // ...
}

As you can see, the ...$params syntax tells the function to accept the first parameter as is, and to put all the others into the $params array. This rids us of the splicing and calling func_get_params, improves function signatures, and makes the code more readable.

The new syntax also allows passing of extra arguments by reference, by prefixing ...$params with an ampersand, like so: &...$params. This was not possible before with func_get_args.

Argument unpacking

Note: thanks to nikic for pointing out this feature – it got implemented around the time of this article’s original writing

Following improved support for variadic functions, argument unpacking got approved, too.

Until now, the only way to call a function with an arbitrary number of arguments passed in as params was by using call_user_func_array meaning literally “call userland function with array of params”. This was clumsy and awkward, wasn’t supported in constructors, was slow, and required a callback in the form of a string – a function name – which means no IDE support in most cases.

Unpacking would eliminate all the downsides of said function, and naturally complements the variadic support seen above. Unpacking works like so:

$args = [1, 3, 5, 7, 9];
MyClass::someMethod(...$args);

This is the same as calling

MyClass::someMethod(1, 3, 5, 7, 9);

i.e. passing in the arguments in one by one. This works in any concievable scenario, from class constructors to being called multiple times in a call, anything goes. See the RFC linked above for usage examples and further explanations.

Constant Scalar Expressions

This RFC added the ability to have expressions in places that only expect static values. What this means is you can now have basic arithmetic and logical structures in constant declarations, functions arguments, class properties etc.

For example, previously, code like this would throw an error:

const a = 1;
const b = a?2:100;

Now, this is no longer the case.

One might argue whether a constant really is constant if it depends on the value of another constant, but such meta discussions are better left for other times.

PHPDBG bundled by default

The gdb-like debugger, phpdbg, is now bundled by default as SAPI. It’s used from the command line, or a simplistic Java UI, specifying break points interactively, altering programs at runtime and more. It can also inspect Opcode, and be used from withinyour PHP code. Learn more about phpdbg here.

Zip improved

The Zip library got several improvements, particularly in the form of new methods. One that stands out especially is ZipArchive::setPassword($password) which finally allows you to easily create password protected Zip files.

Importing namespaced functions

As per this RFC, the new version will allow importing of namespaced functions and constants. Right now we are able to import namespaces and types (classes/interfaces/traits) via the use statement, like so:

namespace foo\bar {
    function baz() {
        return 'foo.bar.baz';
    }
}

namespace {
    use foo\bar as b;
    var_dump(b\baz());
}

From 5.6, we’ll be able to use the use function and use const statements to import a lone function or constant (even class constant).

namespace {
    use function foo\bar as foo_bar;
    use const foo\BAZ as FOO_BAZ;
    var_dump(foo_bar());
    var_dump(FOO_BAZ);
}

Conclusion

PHP 5.6, which as of this moment still doesn’t have a release date, definitely looks promising, and hopefully this short overview of the changelog helped you understand how important it will be for you to upgrade as soon as it’s out, if at all. For the remainder of the upgrades, please see the NEWS file, and keep checking back for updates. If I’ve missed something important, or misinterpreted something, please let me know in the comments below.

PHP & MySQL: Novice to Ninja, 7th Edition