Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71101
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
Message-ID: <52D301F3.9010600@gmail.com>
Date: Sun, 12 Jan 2014 20:58:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com> <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com> <52D2ED5F.4000706@gmail.com> <52D2EE69.9070806@ajf.me>
In-Reply-To: <52D2EE69.9070806@ajf.me>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFC
From: rowan.collins@gmail.com (Rowan Collins)

On 12/01/2014 19:35, Andrea Faulds wrote:
>
> This is why I proposed earlier that we should make => in function 
> calls work identically to array syntax, such that { const bar = 
> "foobar"; foo(bar => 3); } would be the same as foo("bar" => 3);
>
> However, strings are quite inconvenient. So I suggest a new, 
> bareword-only syntax, namely the colon. foo(bar: 3); would never mean 
> the constant, and only mean the parameter named bar. We could then add 
> this syntax to array declarations: [bar: 3, "foo" => 7]
>
> It would allow a shorter form while avoiding inconsistency with array 
> syntax. 

The question, is, is the parser robust enough to guarantee that the 
following will all be parsed correctly:

do_soap_call(namespace: 'foo');
check(if: $arriving === true, true: 'Hello', false: 'Goodbye');
$callback = array( function: function() { }, array: array( ) );

I can't think of a case off the top of my head where it would be 
*theoretically* impossible, but that doesn't mean it would be trivial to 
implement, and if there were any cases where it couldn't be used, I'd 
personally much rather it didn't exist at all. (And what about secondary 
parsers, e.g. syntax highlighters?)

I'm also not convinced that it's something worth having more than one 
way to write, as it just makes code harder to read for new coders: will 
it be obvious that [bar: 3] is the same as ['bar' => 3], but not the 
same as [bar => 3], except when it is, because of "undefined constant, 
assumed string" fallbacks...?

I think I'd personally lean towards using a $ to mark named parameters, 
and simply not allow dynamically choosing which parameter gets passed 
(that strays close to "variable variable" territory anyway, of which I'm 
not a fan). If I think of the function signature "function foo($bar) { 
... }", I would tend to think of the argument as "$foo" not "foo" 
anyway, so it doesn't seem a stretch that "foo($bar => 3);" would mean 
"call function foo(), with argument $bar set to 3".

Regards,

-- 
Rowan Collins
[IMSoP]