Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74683
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.248 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: <CADajX4DJQZUnM5vHN_aLHCu6i_mg--sFEvrw9qrySL1o_yiyYA@mail.gmail.com>
Date: Sun, 1 Jun 2014 21:03:32 +0100
Cc: Rowan Collins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <FBB85D36-E37A-4227-889C-20096DA76A6E@ajf.me>
References: <6E3D6B3F-1BD6-42A2-B59C-12B9D6D597ED@ajf.me> <538B8364.6000903@gmail.com> <CADajX4DJQZUnM5vHN_aLHCu6i_mg--sFEvrw9qrySL1o_yiyYA@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Subject: Re: [PHP-DEV] [RFC] Bare Name Array
From: ajf@ajf.me (Andrea Faulds)


On 1 Jun 2014, at 20:56, Adam Harvey <aharvey@php.net> wrote:

> 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).

The problem with Ruby-style symbols is twofold. First, we don=92t have a =
free character in PHP to use to denote a symbol, so it would have to be =
two characters. In that case, there=92d be no advantage in using it over =
a string. Secondly, Ruby-style symbols are completely separate from =
strings, with symbol keys and string keys being different. Nothing in =
PHP deals with symbols, however, everything deals with strings. So for =
it to be useful we=92d either have to start using it everywhere, which =
won=92t happen, or have it just be another syntax for strings, which =
would be useless as it=92s no shorter.

> 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 =97
> 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.

I=92m not entirely sold on :> either, but it=92s the best idea I=92ve =
had so far. I made a single RFC as I think the two features are =
complementary. As both use T_STRING, anything you can define with : you =
can dereference with :>, and the colon in :> is obviously inspired by =
the colon syntax. I may consider splitting the proposals into their own =
RFCs yet, though. I want to hold separate votes, anyway.

--
Andrea Faulds
http://ajf.me/