Re: [RFC] Bare Name Array

From: Date: Tue, 03 Jun 2014 20:34:54 +0000
Subject: Re: [RFC] Bare Name Array
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-74730@lists.php.net to get a copy of this message
On 03/06/2014 02:14, Andrea Faulds wrote:
Something I’m considering adding to the RFC is support for quoted names, such that you could do this: [“stringKey”: 3]
I noticed when hunting for the old discussion that this version - with colon, but quoted - was a vote option when the square bracket syntax was first brought in (needless to say, it didn't pass the vote, although that doesn't mean it wouldn't today). See "Array short syntax" section on https://wiki.php.net/todo/php54/vote Personally, I think its distinctive role as turning a bare-word into a string key is the only justification for this syntax at all, and if I ever used it, it would be exclusively for "struct"-type arrays, where the keys adhered to a strict template. In fact (similar to the discussion of "symbols" earlier) a new "struct" type (copy-on-write like an array, but with keys never added or removed after declaration) might be an interesting idea to explore. Allowing quoted strings on the left-hand side also opens up questions about other possibilities: if you can have quoted strings, why not numeric keys as well? And then, what about [$foo: 'bar']? Is that still a syntax error, and if so, will it be obvious to users why that is? And then we're back to the bare-word=constant problem again: the only distinction between ":" and "=>" would be "force the left-hand side to be evaluated as a string, not a constant name", which just seems kind of confusing. The author of phpsadness.com may disagree, but then they also copmlain that declaring a function with a reserved name (__lambda_func, those two underscores screaming "reserved for internal use") breaks a feature which you should never need to use anyway since PHP 5.3 [http://phpsadness.com/sad/39]; and that fork() and exec() aren't present in PHP, except, y'know, when they are, because they mistook "in an optional extension" to mean "scary and non-standard" rather than "modular" [http://phpsadness.com/sad/17]. So I'm not inclined to take their advice on how the language should work (I bring this up because the RFC cites this as an inspiration, and I've been considering a blog-post debunking that site for a while now). Regards, -- Rowan Collins [IMSoP]

« previous php.internals (#74730) next »