Re: [RFC] Named parameters

From: Date: Fri, 06 Sep 2013 17:25:34 +0000
Subject: Re: [RFC] Named parameters
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-68914@lists.php.net to get a copy of this message
On 6 September 2013 09:39, Nikita Popov <nikita.ppv@gmail.com> wrote: > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in > particular. Thanks for proposing this. I haven't looked at the patch yet, but I'm all for the feature. My thoughts on your open questions: Syntax: I suspect this will end up having to go to a vote (classic bikeshed), but I'm on the func('foo' => 'bar') train. :foo doesn't make sense in a PHP context (we'd have to implement that across the language, not just for function calls), : as a key-value separator would only work if it was also supported in array literals, and = feels a little wrong for this. I don't really like the unquoted parameter names so much; it's inconsistent with array literals and bare words as strings is something that's been discouraged for a long time. 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. call_user_func_array: for consistency, we might want to consider adding an analogue function that deals with named parameters, even though it would work via $callable(...$kwargs). Contracts: I agree with you, basically — it would have to be an E_STRICT or thereabouts, with the possibility of revisiting come a hypothetical PHP 6. Adam

« previous php.internals (#68914) next »