Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <538E316E.8080105@gmail.com>
Date: Tue, 3 Jun 2014 21:44:36 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <238F3085-29E5-473C-9668-BA937BD538FE@ajf.me>
References: <6E3D6B3F-1BD6-42A2-B59C-12B9D6D597ED@ajf.me> <3A13FF39-6AF4-4A0C-A503-897C39023768@ajf.me> <538E316E.8080105@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Bare Name Array
From: ajf@ajf.me (Andrea Faulds)


On 3 Jun 2014, at 21:34, Rowan Collins <rowan.collins@gmail.com> wrote:

> 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.
>=20
> 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=3Dconstant problem again: the only =
distinction between ":" and "=3D>" would be "force the left-hand side to =
be evaluated as a string, not a constant name", which just seems kind of =
confusing.

Yeah. Upon further reflection, I think supporting strings too would be =
silly here. My only real rationale was to parallel my hypothetical =
future object literals, but that=92s silly. (Also, looks like I can=92t =
implement them anyway.)

On a different topic, structs are indeed an interesting idea. Perhaps =
they could be a resurgence of PHP4-style objects? I note that Apple=92s =
new =93Swift=94 language has structs and classes, where it seems structs =
are essentially identical to classes except that they have value instead =
of reference semantics. But that is a discussion for another thread.
--
Andrea Faulds
http://ajf.me/