[RFC] Named parameters

Regarding variable parameter names; if the syntax was:

function foo( $firstParameter ) { ... }
foo( $firstParameter=> 'foo' );

Then the double-dollar syntax would seem the obvious choice to me:

function foo( $firstParameter ) { ... }
$param = 'firstParameter';
foo( $$param => 'whatever' );

Which is no less readable than anywhere else the double-dollar is
allowed... :-p

--G

Hi Nikita

First of all, thanks for your proposal.
I'd like to make some comments, see below.

-----Original Message-----
From: Lazare Inepologlou [mailto:linepogl@gmail.com]
Sent: Friday, September 06, 2013 7:55 PM
To: Adam Harvey
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Named parameters

2013/9/6 Adam Harvey aharvey@php.net

Variadics/splat: collecting both named and positional arguments into
one array seems reasonable to me. I think the main use case there
would be option parameters, which you'd have to validate anyway, so
positional parameters would be dealt with at that point — I don't see
separate arrays as conferring any great advantage in terms of
validating parameters, and it's no simpler conceptually.

There is a small drawback. Suppose this code:

function foo( $bar = 0 , ...$args ){}
foo( bart => 3 ); // misspelled name

According to the RFC, any unknown argument name will fall into the $args
array, making the above code valid. As this cannot be verified statically, it is a
possible source of bugs.

Lazare INEPOLOGLOU
Ingénieur Logiciel

I agree with Lazare, it seems wrong to me to mix *args and **kwargs and put everything in one argument. Especially because this will hide bugs for sure, but also because if I want to use *args then I do not want necessarily support **kwargs as well (as mentioned in your cons).
Btw did I miss something? I could not read anything about **kwargs in your variadics RFC. Because you do not want to introduce it together with *args?

I now assume you do not want to introduce **kwargs and handle everything with *args. That's why you came up with the idea to put everything in *args, right?

I'd like to outline an example where **kwargs would be very useful. Sorry, somehow off-topic but that's just because this RFC refers to other RFCs which are not yet accepted. I think it's not a good idea to start mixing several RFC. It almost seems like variadics, argument unpacking and named parameters can only coexist together. But anyway... now I go the same way :P

**kwargs is very useful if you want to have a type for *args and some options for **kwargs
Let's say I have defined a function which renders an arbitrary number of contact details (one contact per row) and you want to be able to pass in some additional html attributes which shall be applied for each <tr>.

function renderAsTable(array $htmlAttributes, Contact ...$args){}
renderAsTable(['class' => 'someClass', 'validate'=>'true'], $contact1, $contact2);

vs.

function renderAsTable(Contact ...$args, =>...$htmlAttributes){} // =>... should stand for **kwargs, I do not like this syntax but nothing else came into my mind right now
renderAsTable($contact1, $contact2, 'class' => 'someClass', 'validate'=>'true');

I know, the first syntax doesn't seem to be too bad yet (apart from ['class' => 'someClass', 'validate'=>'true'] is almost looking like named arguments, maybe => isn't a good choice and we should prefer something else?) but consider when you combine it with argument unpacking

renderAsTable(array_merge($arr, ['class' => 'someClass', 'validate'=>'true']), ], $contact1, $contact2);

vs.

renderAsTable($contact1, $contact2, 'class' => 'someClass', 'validate'=>'true', ...$arr);

I prefer the second version and I guess you agree that variadics shall be introduced to reduce array_merge. Thus it seems logical to me to introduce **kwargs as well and therefore I would not mix them and put everything only in one argument. Otherwise you will have problems to introduce **kwargs later on.

You could argue one could write the second version and handle everything in the function. But I am pretty sure that no one wants to have such an overhead either. Something like:

function renderAsTable(...$args){
$htmlAttributes = []
$contacts = []
foreach($args as $key => $value){
if($value instanceof Contact){
$contacts[] = $value;
} else {
$htmlAttributes[] = $value;
}
}
//now do your stuff
}

You could also argue, that one just need to write the function in a different way:

function renderAsTable(array $contacts, ...$htmlAttributes){}

Might work as a workaround in this case, but then I lose the ability to have a type checked array ;-)

Cheers,
Robert

Hi Adam

I'd say the odds are that those sorts of users are going to be writing
code that is required to be notice/strict clean anyway — that's
certainly been true everywhere I've worked that's had a "modern"
codebase.

Yes, so say you have a team that:

• currently has a code base that is notice/strict clean
• wants to move to PHP 5.x which has named parameters
• have code which changes the param name in extends/implements

Unless they rewrite their code, they wouldn't be able to upgrade next
version of PHP without losing their strict/notice cleaness. So how would
you suggest they upgrade to the version of PHP with named parameters?

Also I'm not sure that having which error level is used actually changes
the behaviour of the language in a meaningful way. It only suppresses a
particular warning message, which can be suppressed anyway with
error_reporting(0).

cheers
Dan

If named parameters are introduced, signature validation should include
parameter names. Throwing a fatal error (for the interface/class
combination)
would break backwards compatibility though. We could use some lower
error
type...

Would it be possible to set the error level through an ini setting? Or
disable it entirely?

I've said this before, but to reiterate it: I'd be a huge -1 on
anything that involves configurable language behaviour. It's a support
nightmare, and I'm glad those days are now mostly over.

People who are writing new code that is aware of named parameters should
want a fatal error for any coding mistake that violates the contract.

I'd say the odds are that those sorts of users are going to be writing
code that is required to be notice/strict clean anyway — that's
certainly been true everywhere I've worked that's had a "modern"
codebase.

Adam

Matthew Leverton wrote:
This is already the case. In libraries that accept options via an array,
those array keys are pretty much set in stone (although you can map them
if you need to change a key).

The big difference here is if I accept an options array, I understand
that the keys are important and would never break backward
compatibility by changing a parameter name. This isn't a case of "if
you don't like it, then don't use it" because every function I create
now has to respect the possibility of accepting named parameters,
whether I care about it or not. And I sure hope every function I call
is created by and maintained by somebody with those same
sensibilities.

My opinion is that this really isn't as cool as it sounds, especially
since we have short array syntax. Again, I don't really care if it's
accepted into PHP, but I think it will be more of a minor nuisance for
me than anything else.

--
Matthew Leverton

On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess
michael@mjburgess.co.uk wrote:

The position of parameters and the name of the function must already be
maintained... I dont see why appropriately naming variables is such a
burden.

I wouldn't necessarily make this objection if this were a day-1
feature. But it does bother me somewhat that all of a sudden code
retro-actively starts supporting named parameters.

The OCD in me shudders to think about now having to parse through
people's code like:

substr('length' => 1, 'string' => 'Hello World');

Now I see the function, and I have to see how they ordered their
parameters. Why was 'start' omitted... is this a warning due to using
NULL as an int.. did the person mean 'start', etc? It's just one
example, but I know that this sort of code will start cropping up
everywhere. So that's why I call this a nuisance. It just seems like a
very marginal gain for lots of potential headaches.

But I don't mean to make a mountain out of a molehill. After giving it
some thought, I'd like some consideration to be given to providing an
explicit syntax in the RFC at least so people consider all
alternatives.

I just don't think that giving people the ability to call a function
with two well ordered parameters by using named parameters is worth
causing all future code to diverge into two drastically different
calling styles.

My strong preference would be a syntax that separates the two types of
parameters, such as the following:

function func($a, $b, ...$params, [$c = 'foo', $d = 'bar'])
{

}

func($a, $b, $extra, 'd' => 'override');

Here $a and $b are not named parameters and must be present. Extra
positional parameters are sent to $params. The parameters enclosed in
square brackets must be passed in by name as the last parameters, but
can be omitted.

I don't like the $ on the named parameter when calling because it
implies that this works:

$d = 'c';
func($a, $b, $extra, $d => 'override');

Now is 'c' overridden or 'd'?

So I'll give this issue a rest unless somebody wants to further
discuss what the concrete syntax might look like.

--
Matthew Leverton

Nikita,

I agree with your views, although, I think your last suggestion comes
close to being close to some sort of weird method overloading (the way
I understood it).

Uh, I think this is a misunderstanding caused by my bad phrasing. I'll try
to clarify:

class A {
    public function foo($oldBar) { ... }
}

class B extends A {
    public function foo($newBar) { ... }
}

$b->foo(oldBar => $xyz);

Here $b->foo() will call B::foo(), not A::foo(). The thing about
looking at the parameter names of the parent methods is just to make sure
calls are compatible with the parameter names of parent methods, even if
those names were changed during inheritance. We do not actually call the
parent method, we just borrow the parameter name from there.

In fact I'm not sure if the other way around should be the norm; where

we'd force the dev to implement the same args as the parent (like it
is now: i.e. type hinting, same signature, etc); even if it's just to
do an unset($oldbar) inside something like B::foo($newBar, $oldBar =
NULL)

Yes, throwing an error during the signature validation is the "right" thing
to do from a theoretic point of view. The issue is just that it breaks old
code which didn't make sure that parameter names between parent and child
lined up. "Break" is a bit too much here as it would still run, just
throwing an E_STRICT. This is what I'd like to go for, but others disagree
so I tried to offer an alternative solution.

Nikita

I created an RFC and preliminary implementation for named parameters:

https://wiki.php.net/rfc/named_params

I really like the idea!

My preference would be to only support named parameters based on the initial declaration $oldBar (much simpler expectations).

I bet that there is already many code "renaming" the parameters so I
agree with Nikita to match it against the called instance (and not the
initial declaration).

As for the open questions I would prefer something from the "can use
keywords" section.
I think one with the dollar sign would be best since thats how the
declaration looks like, e.g. "$foo => xxx" or "$foo: ...".

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/');
No. With positional arguments:

 function foo($bar, $foobar, ...$x) {}
 foo(1, 2);

Then $x will be empty, since it only collects "left-over" arguments, I
suppose. The same applies for named arguments. In the case you used,
$args would be empty, as $method and $url pick up those named arguments.

Andrea Faulds
http://ajf.me/