Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74681
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <538B8364.6000903@gmail.com>
References: <6E3D6B3F-1BD6-42A2-B59C-12B9D6D597ED@ajf.me> <538B8364.6000903@gmail.com>
Date: Sun, 1 Jun 2014 12:56:03 -0700
Message-ID: <CADajX4DJQZUnM5vHN_aLHCu6i_mg--sFEvrw9qrySL1o_yiyYA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>, Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Bare Name Array
From: aharvey@php.net (Adam Harvey)

On 1 June 2014 12:47, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 01/06/2014 18:59, Andrea Faulds wrote:
>>
>> The first is a less cumbersome syntax for arrays. At present, string key=
s
>> in arrays are declared like this:
>>
>> =E2=80=9CstringKey=E2=80=9D =3D> 3,
>>
>> [...] Where the key fits the profile of IS_STRING, this RFC proposes tha=
t
>> you can do this instead:
>>
>> stringKey: 3,
>
>
> Interestingly, I notice Ruby's hash syntax has two variants very similar =
to
> this [http://www.ruby-doc.org/core-2.1.2/Hash.html].
>
> However, in that case, the unquoted version represents a use of Ruby's
> special "Symbol" type, which is actually a different fundamental type fro=
m a
> String. So the following actually defines a 2-element hash, with one Symb=
ol
> key and one String key:
>
> foo =3D { myKey=C2=AD: 'bar'=C2=AD, 'myKe=C2=ADy' =3D> 'bob'=C2=AD }
> =3D> {:myKey=3D>"bar", "myKey"=3D>"bob"}

You've mostly pre-empted the question I wanted to ask. :)

Andrea, did you consider implementing something more like Ruby's
symbols, rather than a variation on the existing array literal syntax?
I feel like that might solve any potential ambiguities in terms of
constant resolution (as mentioned in another subthread), wouldn't
require a separate [foo: bar] variant on the existing syntax, and may
be useful in other contexts too (such as array dereferencing).

As for the array dereferencing syntax: it should probably be an RFC
and patch on its own. To be honest, my initial reaction is negative =E2=80=
=94
I think the proposed syntax blurs the lines between arrays and objects
(I know it's a different digraph, but it's going to look really
similar when scanning code), and I'm not yet sold on it being
particularly useful.

Adam, who's living in the future and typing this from an airborne
plane. Very exciting.