Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gdesolutions.com designates 207.46.163.242 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>, PHP internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: [RFC] Named parameters
Thread-Index: AQHOrZZ/S59eH1tvtEum/HBc3NuaTJm+zhzw
Sender: Jonathan Bond-Caron <jbondc@gdesolutions.com>
Date: Wed, 11 Sep 2013 12:16:03 +0000
Message-ID: <a329e809289344a8abf0f0524db2d874@BN1PR07MB135.namprd07.prod.outlook.com>
References: <CAF+90c85v_VTPTPanBcTJ70Ff6pm6fRgAGs4n1uoaA+B9UZg=w@mail.gmail.com>
 <CAF+90c8qj_3is8Dj4XbkUwL1Y8eVCEPXVYfwhDdaabHWuGzY2Q@mail.gmail.com>
In-Reply-To: <CAF+90c8qj_3is8Dj4XbkUwL1Y8eVCEPXVYfwhDdaabHWuGzY2Q@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Re: [RFC] Named parameters
From: jbondc@openmv.com ("jbondc@openmv.com")

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
> >
>=20

Awesome work!

>=20
> Let only special functions accept named params
> -----
>=20

Proposal makes sense though there's still the challenge how to deal with th=
e '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 =3D> 'post', url =3D> 'foo/');

> Renaming of parameters in signatures
> -----
>=20
> 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.
>=20
>     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 initia=
l declaration $oldBar (much simpler expectations).

$c =3D new B;
$c->foo(oldBar =3D> 'hello');
$c->foo(newBar =3D> '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.=20
Some ideas for a different syntax:

$params =3D ['oldBar' =3D> '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 na=
med parameters.