On Mon, Sep 23, 2013 at 11:18 PM, Robert Stoll <rst...@tutteli.ch> wrote:
> Personally I would allow multiple unpacking but not allow unpacking for
> non-variadic parameters thus:
>
> function foo(...$arr){} foo(...$arr, ...$arr2); //is fine
> function foo(...$arr){} foo(1, 2, ...$arr, ...$arr2); //is fine
> function foo($foo, $bar, ...$arr){} foo(1,2,...$arr, ...$arr2); //is fine
> as
> well
> function foo($foo, $bar, ...$arr){} foo(1, ...$arr, ...$arr2, 2);
> //shouldn't be allowed IMO - ...$arr is not passed to a variadic parameter
>
Introducing such a restriction doesn't make sense. A large number of uses
(you might even say "most of the uses") of call_user_func_array is in call
forwarding. In such cases the target function is usually not variadic. Also
don't forget that PHP always supported variadics via func_get_args() and
I'd like to continue supporting that style as well. Anything that tries to
match up the unpack with a variadic arguments drop the utility of this
feature to about zero.
> I think the readability is harmed when the user is not able to tell
> directly
> which arguments are passed to which parameters. For instance:
> function foo($foo, $bar){}
> function bar($foo, $bar, ...$arg){}
>
> function doIt(Iterator $iterator){
> foo(...$iterator);
> bar(...$iterator);
> }
>
> Depending on the implementation of $iterator the value passed to the
> parameters $foo and $bar will be different (regardless of the ...$arg in
> function bar) and you will have a hard time to understand the code quickly.
>
Sorry, I don't understand what you're saying here. Unless your $iterator is
some weird "output random stuff"-iterator, I don't see why the arguments to
$foo and $bar would be different. If $iterator is a one-time iterator, the
second call will simply fail (just like any time when you use a one-time
iterator twice...)
Nikita
