Possible PHP 5.6 Features

I originally wanted to write a quick round-up of all the discussions from the internals mailing list regarding PHP 5.6. That post was turning out to be rather long, so instead I’m going to focus in on a group of RFCs that are related to how PHP handles function parameters. It’s important to remember that these features have not been accepted into the language yet, so it’s entirely possible that they will not make the actual release of PHP 5.6.

Skipping Parameters

This is a straightforward feature that makes working with optional parameters a little easier. It allows passing the keyword “default”, when you aren’t going to specify your own value for the parameter. For example, if you have a function signature like this:

function foo($param, $param2=’a’, $param3=0, $param4=”) {…}

You can call it like this:

foo(‘value’, default, default, ‘another value’)

This essentially saves you from having to check the function signature and make sure that you are passing the correct default parameters, when you aren’t specifying them your self.  Discussion about this feature is ongoing, so there has been no vote on the RFC yet.

Named Parameters

Named parameters are a better approach to solving the same problems that the Skipping Parameters RFC addresses. It’s been discusses a number of times in the past, but was usually considered too difficult to implement, so the skipping parameters idea was a middle ground between implementation and functionality. However, Nikita Popov announced to the internals mailing list that he has a partial implementation of this feature and has posted an RFC for further discussion.

Named parameters work by letting you pass params to a function by their name, rather than by position. So given the function signature from my previous example:

function foo($param, $param2=’a’, $param3=0, $param4=”) {…}

You could call it like this:

foo(param => ‘value’, param4 => ‘another value’)

This has the advantage of looking a lot cleaner, you also don’t have to worry about the function signature changing later and then adding or removing default params so that your function call still works. Another great benefit is that the code is self documenting and easy to understand at a glance.

The final syntax for this is still up in the air, the RFC proposes several variations and there is also a discussion about this on the mailing list. I’m partial to foo(:param => ‘value’, :param2 => ‘value2’), which I think looks clean and consistent with the PHP language as a whole. That being said, the final syntax is not a huge concern to me, I’ll just be happy if this RFC is accepted into the language.

Variadic Functions

Variadic functions are functions that accept a variable number of arguments, this is a feature that is actually already supported by PHP via the func_get_args() function. This implementation is a little clunky and it’s also not always clear that a function is expecting a variable number of parameters, since the func_get_args() call can happen at any point in a function body.

This RFC would introduce a new syntax that makes it clear that the function is a variadic function:

function foo($param1, …$params) {}

If this function is called with more than one param, all the additionally parameters are stored in an array called $params. You can easily see that this function is variadic by the presence of the …$params syntax.

This RFC has not yet been voted on, you can follow the discussion of this feature on the mailing list.

Argument Unpacking

This feature is commonly referred to as a ‘splat operator’, it allows for passing a list of parameters as an array. The syntax proposed by this RFC looks like this:

$params = array(1,2,3,4);

foo(‘value1’, …$params);

This would be equivalent to calling the function like this:

foo(‘value1’, 1, 2, 3, 4);

As you can see, this feature is essentially a compliment to the variadics feature. This RFC has also not been voted on, you can follow the discussion on the mailing list.

Wrap Up

So that’s a quick round-up of RFCs related to parameter handling in PHP 5.6. In the future I may write a more detailed post about some of these features, but for now I mainly wanted to point people in the direction of the mailing list discussions that are currently ongoing.

If you’re a PHP developer, I highly recommend that you subscribe to the internals mailing list and keep up to date with where the language is going in the future. If you’re unfamiliar with the RFC process that is used to develop the language, then I recommend reading this great overview of how the process works.