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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
