Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74694
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <6E3D6B3F-1BD6-42A2-B59C-12B9D6D597ED@ajf.me>
References: <6E3D6B3F-1BD6-42A2-B59C-12B9D6D597ED@ajf.me>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 02 Jun 2014 10:55:41 +0200
Message-ID: <1401699341.2282.13.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Bare Name Array
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Sun, 2014-06-01 at 18:59 +0100, Andrea Faulds wrote:
> Good evening,
> 
> I have created an RFC containing two proposals.
> 
> The first is a less cumbersome syntax for arrays. At present, string
> keys in arrays are declared like this:
> 
> “stringKey” => 3,
> 
> That’s a whole five characters, seven including spaces, for your most
> common case (identifier-like key). In JavaScript, you can avoid
> quoting the key for this common case. I propose something similar for
> PHP. Where the key fits the profile of IS_STRING, this RFC proposes
> that you can do this instead:
> 
> stringKey: 3,
> 
> Now it’s only two characters, three including spaces, for the most
> common case. It makes declaring arrays more convenient.

I don't believe in "less characters is better". I consider having two
syntaxes which work *notably* different confusing.

   const FOO = 23;
   $a = [
       FOO => 42,
       FOO: 3.14152
   ];

will lead to quite confusing results. We shouldn't go there imo.

> The second proposal is a less cumbersome syntax for dereferencing
> arrays with string keys. At present, you need to do this:
> 
> $myArray[“foobar”][“andSoOn”][“moreKeys”][“etc”]
> 
> That’s four characters per dereference. Yet for objects, only two are
> needed:
> 
> $myObject->foobar->andSoOn->moreProps->etc
> 
> Thus, this RFC also proposes the following syntax for dereferencing
> arrays with string keys, where said keys fit the profile of IS_STRING:
> 
> $myArray:>foobar:>andSoOn:>moreProps:>etc
> 
> The :> syntax can be considered provisional, I’m open to better
> alternatives.

Same as above - the benefit is minimal and might be easily misleading.

johannes