Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71098
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.240 as permitted sender)
Message-ID: <52D2EE69.9070806@ajf.me>
Date: Sun, 12 Jan 2014 19:35:05 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com> <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com> <52D2ED5F.4000706@gmail.com>
In-Reply-To: <52D2ED5F.4000706@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Revisiting the "Named Arguments" RFC
From: ajf@ajf.me (Andrea Faulds)



On 12/01/14 19:30, Rowan Collins wrote:
>
> Personally, I'm against allowing barewords to act as strings wherever
> they don't - currently - clash with keywords, for two reasons:
>
> Firstly, the concept in general is prone to errors in the programmer's
> memory and the evolution of the language regarding which words are and
> aren't allowed. One of the few differences between JSON and an actual
> Javascript object declaration is that keys in JSON are *always* quoted,
> and I think that was a good move on Crockford's part. People get in the
> habit of using unquoted object keys in JS, and then have to dig through
> the code to figure out which name some parser is choking on.
>
> Secondly, barewords already have a specific meaning in PHP: constants.
> By convention, constants are UPPER_CASE, but the engine doesn't actually
> care, and array(foo => bar) is actually valid PHP, but might be
> equivalent to array('six by nine' => 42), if that's what 'foo' and 'bar'
> are define()d as.
>
> I'm glad the introduction of shortened array syntax didn't change this
> meaning, and am not convinced named parameters should either, unless the
> syntax is chosen to *always* use barewords, with no variable
> interpolation or ambiguity.
>
> As an aside, what I *would* like to see is the end of the "if a constant
> isn't declared, assume it's actually a string" fallback, which feels
> like a hangover from PHP's pre-history. The fact that an undeclared
> class constant is a fatal error, but an undeclared global constant is a
> notice is one of those inconsistencies for which PHP is notorious.
>

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.

-- 
Andrea Faulds
http://ajf.me/