Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71097
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Message-ID: <52D2ED5F.4000706@gmail.com>
Date: Sun, 12 Jan 2014 19:30:39 +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: internals@lists.php.net
References: <581A185E-0F00-4B49-AA87-859D75E63BA2@googlemail.com> <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.gmail.com>
In-Reply-To: <CAJ26g5Q40RH9c80r0=7wQNoBnciNi-=n_VdAaDMfqbqbwKfpJw@mail.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: rowan.collins@gmail.com (Rowan Collins)

On 12/01/2014 08:16, Patrick Schaaf wrote:
> Regarding Syntax at the call site, I feel that it is exactly right the way
> it is proposed / implemented now. That way mirrors most closely the syntax
> of static array definition, while saving some typing (omitting of double
> quotes) where key names do not clash with keywords. In fact, once
> established, I would love static array initialization to also permit
> nonclashing keys to omit the doublequotes :)

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.

Regards,

-- 
Rowan Collins
[IMSoP]