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]