On Mon Sep 9 03:18 PM, Nikita Popov wrote:
> > I created an RFC and preliminary implementation for named parameters:
> >
> > https://wiki.php.net/rfc/named_params
> >
>
Awesome work!
>
> Let only special functions accept named params
> -----
>
Proposal makes sense though there's still the challenge how to deal with the 'api
mismatch' problem.
I'm still undecided about 'mixing' positional & named arguments:
An example use case for **kwargs here:
http://www.python-requests.org/en/latest/api/
If you declare:
request($method, $url, ...$args)
Would $args collect 'method' and 'url' ?
request(method => 'post', url => 'foo/');
> Renaming of parameters in signatures
> -----
>
> Until now three options were discussed:
> 1. Throw an E_STRICT (or similar) error during signature validation if a parameter
> is renamed 2. Don't validate parameter renames in signature and just let people
> hit the runtime error when they do the call.
> 3. Create an ini-setting chooses either behavior 1 or 2.
>
> class A {
> public function foo($oldBar) { ... }
> }
> and
> class B extends A {
> public function foo($newBar) { ... }
> }
My preference would be to only support named parameters based on the initial declaration $oldBar
(much simpler expectations).
$c = new B;
$c->foo(oldBar => 'hello');
$c->foo(newBar => 'hello'); // Warning, no named parameter 'newBar' found,
Warning first argument missing ...
Lastly, using the same syntax "..." for declaring variadics and "unpacking"
seems odd to me.
Some ideas for a different syntax:
$params = ['oldBar' => 'hello'];
$c->foo($params...);
$c->foo((var)$params);
$c->foo((...)$params);
My preference is the third since it looks like we're casting an array to named parameters.