What can change with the variadic Function implementation?

Question

PHP 5.6 implemented a feature called Variadic Function.

It is as if they were infinite arguments. They can be used both in the statement of a function as for the calling.

Examples PHP 5.6

Example in the statement:

function test($arg, ...$args)
{
    print_r($args);
}

test('first argument', 1, 2, 3); // imprime: array(1, 2, 3);

Example in the call:

function test($first_name, $last_name)
{
    return "{$first_name} {$last_name}";
}

$args =  ['Wallace', 'Maxters'];

$alias = 'test';

$alias(...$args); // Wallace Maxters

test(...$args); // Wallace Maxters

Examples versions prior to 5.6

These examples if used in versions prior to 5.6, could be done as follows:

Statement example:

function test($arg)
{
    $args = array_slice(func_get_args(), 1);
    
    print_r($args);
}

test('first argument', 1, 2, 3); // array(1, 2, 3)

Example calling:

function test($first_name, $last_name)
{
    return "{$first_name} {$last_name}";
}

$args = ['Wallace', 'Maxters'];

$alias = 'test';

echo call_user_func_array($alias, $args); // Wallace Maxters
echo call_user_func_array('test', $args); // Wallace Maxters

After the implementation of variadic function, for anyone using PHP 5.6, which will be the purpose of the functions call_user_func_array and func_get_args?

That implementation of variadic function could compromise these functions and, in the future, render them obsolete?

Answer 1

I do not follow closely the developments of PHP, but the little I see passes the impression that they are quite conservative, and that even when something is marked as obsolete (deprecated) it can still take a long time to actually be removed. I agree with @gmsantos at this point, PHP avoids creating incompatibilities with legacy code.

As to the two functions cited, the func_get_args I believe it is maintained because it has a function different from the parameter splat of the variadic functions, since it returns all the arguments received. The call_user_func_array also has its role, as it allows the passage of dynamic arguments even if the function is not variable. This is without saying that it allows calling a function by name (as a string), such as the call_user_func. In short, I see reasons for the two functions to be maintained, mainly func_get_args.

Answer 2

In my view the variadic function will replace call_user_func_array and func_get_args.

They would stay there for a few releases to maintain compatibility with code that needs to work in earlier versions of PHP 5.6 until a beautiful day vote to be discontinued.

Don’t expect this to be done soon. The latest versions included alternative syntax for other things, such as array syntax in PHP 5.4, replacing the function array() and the potentiation operator also in PHP 5.6 who does the same thing as the function pow(). Both cases remain valid until it is decided that it is no longer worth keeping them there, as happened several things (example of the extension mysql_*).

Answer 3

Just as a complement to the previous answers: a simple example is to improve the syntax and decrease the function call, improving the performance.

Formerly:

call_user_function_array(array($controller, $method), $parameters);

Currently:

$controller->$method(...$parameters);

Another advantage can be seen in the declaration of methods or functions. Let me give an example that I always use, which is the use of a static method to facilitate the creation of the class instance.

Formerly:

 class Controller {

    public function __construct(Request $request, Response $response)
    {

    }

    public static function make(Request $request, Response $response)
    {
         return new static($request, $respone);
    }

}

Currently:

class Controller {

    public function __construct(Request $request, Response $response)
    {

    }
    /** Não precisa declarar as mesmas coisas de construct, é um atalho **/
    public static function make(...$arguments)
    {
         return new static(...$arguments);
    }

}


Controller::make(new Request, new Response);