# [RFC] Bare Name Array

- Thread: https://externals.io/message/74665
- Original archive: https://news-web.php.net/php.internals/74665
- Started by Andrea Faulds on 2014-06-01T17:59:13+00:00
- Messages: 30
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/74665.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #74665 — Andrea Faulds — 2014-06-01T17:59:13+00:00

URL: https://externals.io/message/74665#74665

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.

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.

The two proposals will be voted on separately, but I’m making a single RFC as they’re related and complement each other.

The RFC is here: https://wiki.php.net/rfc/bare_name_arrays

Please read it and tell me your thoughts. I already have a completely working patch with tests available.

Thanks!

--
Andrea Faulds
http://ajf.me/

---

## #74666 — Stas Malyshev — 2014-06-01T18:13:29+00:00

URL: https://externals.io/message/74665#74666 · In reply to: #74665

Hi!

> 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,

You can already do stringKey => 3 :) And saving characters is not really
a big priority. Changing language syntax and making millions of people
to learn new syntax just to save a couple of chars does not look like a
big win to me.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #74667 — Andrea Faulds — 2014-06-01T18:37:51+00:00

URL: https://externals.io/message/74665#74667 · In reply to: #74666

> You can already do stringKey => 3 :)

Yes, but then you’ll get:
	Notice: Use of undefined constant stringKey - assumed 'stringKey' in Command line code on line 1

> And saving characters is not really
> a big priority.

Well, we already replaced array() with []. I think it is reasonable to consider saving characters in other places. It’s not a *big* priority, no, and we shouldn’t do it excessively, but if common cases are cumbersome, we should try to deal with them.

Array literals with string keys and dereferencing arrays with string keys are extremely common in PHP. So I think this reduction would benefit most users, especially those who deal with JSON and the like (which I do a lot in my on code), as this makes declaring arrays to be serialised more convenient. Also, foobar: just looks nicer than “foobar” =>, especially when you have syntax highlighting.

> Changing language syntax and making millions of people
> to learn new syntax just to save a couple of chars does not look like a
> big win to me.

We did it for array(), I think we should do it again. Also, yes, millions might have to learn the new syntax, but I think it is simple and intuitive. It is not difficult to learn, and hey, perhaps millions can benefit, especially since both target very common cases (I expect they’re the most common, except for numerical indexes) when dealing with arrays.
--
Andrea Faulds
http://ajf.me/

---

## #74669 — Rafael Kassner — 2014-06-01T18:47:21+00:00

URL: https://externals.io/message/74665#74669 · In reply to: #74667

This causes a huge backward incompatibility:

define('KEY', 'foo');
> $data = array(KEY => 'bar');


Should $data have 'foo' or 'KEY' as element? AFAIK, some frameworks use
this constants in array keys.




>
> 
>
> > […]
>
> Yes, but then you’ll get:
>         Notice: Use of undefined constant stringKey - assumed 'stringKey'
> in Command line code on line 1
>
> > […]
>
> Well, we already replaced array() with []. I think it is reasonable to
> consider saving characters in other places. It’s not a *big* priority, no,
> and we shouldn’t do it excessively, but if common cases are cumbersome, we
> should try to deal with them.
>
> Array literals with string keys and dereferencing arrays with string keys
> are extremely common in PHP. So I think this reduction would benefit most
> users, especially those who deal with JSON and the like (which I do a lot
> in my on code), as this makes declaring arrays to be serialised more
> convenient. Also, foobar: just looks nicer than “foobar” =>, especially
> when you have syntax highlighting.
>
> > […]
>
> We did it for array(), I think we should do it again. Also, yes, millions
> might have to learn the new syntax, but I think it is simple and intuitive.
> It is not difficult to learn, and hey, perhaps millions can benefit,
> especially since both target very common cases (I expect they’re the most
> common, except for numerical indexes) when dealing with arrays.
> --
> Andrea Faulds
> http://ajf.me/

---

## #74671 — Andrea Faulds — 2014-06-01T18:49:27+00:00

URL: https://externals.io/message/74665#74671 · In reply to: #74669

> This causes a huge backward incompatibility:
> 
> define('KEY', 'foo');
> $data = array(KEY => 'bar');
> 
> Should $data have 'foo' or 'KEY' as element? AFAIK, some frameworks use this constants in array keys.

‘foo’, I checked. Frameworks doing that should really not be, it’s really bad practise to rely on PHP’s fallback for non-existent constants, and that generates a Notice.

Now you’d have the option of doing array(KEY: ‘bar’) though, which does not resolve the constant.
--
Andrea Faulds
http://ajf.me/

---

## #74672 — Rafael Kassner — 2014-06-01T18:56:13+00:00

URL: https://externals.io/message/74665#74672 · In reply to: #74671

You missed my point, I'm not saying about undefined constants, I'm saying
about the usage of defined constants as array keys. If the array
declaration don't expand constants to strings anymore, many code will
break. If we expand constants within array declaration, someone can mess up
the code by adding a `define()` somewhere above and don't even realize what's
wrong (constants have global scope).




>
> 
>
> > […]
> this constants in array keys.
>
> ‘foo’, I checked. Frameworks doing that should really not be, it’s really
> bad practise to rely on PHP’s fallback for non-existent constants, and that
> generates a Notice.
>
> Now you’d have the option of doing array(KEY: ‘bar’) though, which does
> not resolve the constant.
> --
> Andrea Faulds
> http://ajf.me/

---

## #74673 — Andrea Faulds — 2014-06-01T19:09:35+00:00

URL: https://externals.io/message/74665#74673 · In reply to: #74672

> You missed my point, I'm not saying about undefined constants, I'm saying
> about the usage of defined constants as array keys. If the array
> declaration don't expand constants to strings anymore, many code will
> break.

I haven’t changed that. => still works the same as ever. I’m adding a colon syntax which takes a bare name instead of an expression.

> If we expand constants within array declaration, someone can mess up
> the code by adding a `define()` somewhere above and don't even realize what's
> wrong (constants have global scope).

But that’s how it works at present. People writing array(foo => 3) and assuming that’s the same as array(‘foo’ => 3) need to try turning display_errors on.
--
Andrea Faulds
http://ajf.me/

---

## #74674 — Rafael Kassner — 2014-06-01T19:23:37+00:00

URL: https://externals.io/message/74665#74674 · In reply to: #74673

Sorry, I didn't realize that this would not change the current behaviour.

Should be possible to mix both declarations?

define('FOO', 'bar');
> $data = array(FOO => 'bar', FOO :> 'baz');




>
> 
>
> > […]
>
> I haven’t changed that. => still works the same as ever. I’m adding a
> colon syntax which takes a bare name instead of an expression.
>
> > […]
> what's
> > […]
>
> But that’s how it works at present. People writing array(foo => 3) and
> assuming that’s the same as array(‘foo’ => 3) need to try turning
> display_errors on.
> --
> Andrea Faulds
> http://ajf.me/

---

## #74676 — Andrea Faulds — 2014-06-01T19:25:38+00:00

URL: https://externals.io/message/74665#74676 · In reply to: #74674

> Sorry, I didn't realize that this would not change the current behaviour.
> 
> Should be possible to mix both declarations?
> 
> define('FOO', 'bar');
> $data = array(FOO => 'bar', FOO :> 'baz’);

That would be array(FOO => ‘bar’, FOO: ‘baz’); since :> wouldn’t be used in the literal. But yes, you could mix them. That might be a little confusing, though luckily the intended spacing makes the difference more obvious (FOO => vs FOO:)

--
Andrea Faulds
http://ajf.me/

---

## #74677 — Andrea Faulds — 2014-06-01T19:28:38+00:00

URL: https://externals.io/message/74665#74677

> As others have pointed out, PHP has an additional burden here that *all* barewords in an array literal are currently constant references.

Right. Hence, I add a syntax that treats the string as a bare word rather than a constant. The => operator still works as usual and deals with expressions, but : deals with bare words.
--
Andrea Faulds
http://ajf.me/

---

## #74678 — Stas Malyshev — 2014-06-01T19:34:03+00:00

URL: https://externals.io/message/74665#74678 · In reply to: #74667

Hi!

> Well, we already replaced array() with []. 

That was readability improvement. But it's not a license to make the
language unreadable without any real gain in readability.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #74679 — Andrea Faulds — 2014-06-01T19:46:28+00:00

URL: https://externals.io/message/74665#74679 · In reply to: #74678

> Hi!
> 
> > […]
> 
> That was readability improvement. But it's not a license to make the
> language unreadable without any real gain in readability.

I don’t think readability would be hurt. [ key: value ] is as easy to understand as [ “key” => value ], and likely very familiar to people who have dealt with JavaScript or JSON. The :> operator does not look too far off from -> or =>, too, though again, I’m willing to use a better alternative if one exists.

It also happens to be the C99 digraph for ], take that as you will. :)

--
Andrea Faulds
http://ajf.me/

---

## #74681 — Adam Harvey — 2014-06-01T19:56:03+00:00

URL: https://externals.io/message/74665#74681

> 
> > […]
>
>
> 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 from a
> String. So the following actually defines a 2-element hash, with one Symbol
> key and one String key:
>
> foo = { myKey­: 'bar'­, 'myKe­y' => 'bob'­ }
> => {:myKey=>"bar", "myKey"=>"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 —
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.

---

## #74682 — Andrea Faulds — 2014-06-01T19:56:47+00:00

URL: https://externals.io/message/74665#74682

> 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 from a String. So the following actually defines a 2-element hash, with one Symbol key and one String key:
> 
> foo = { myKey­: 'bar'­, 'myKe­y' => 'bob'­ }
> => {:myKey=>"bar", "myKey"=>"bob”}

To look at another popular language, it’s interesting Perl does the opposite to PHP:

Perl:   %hash = ( ‘key’, ‘value’ );
PHP:    $hash = [ ‘key’ => ‘value’ ]

Perl:   %hash = ( key => ‘value’ );
PHP:    $hash = [ key: ‘value’ ]

While Perl’s => is for unquoted strings, PHP’s is for quoted strings, which is bizarre considering PHP is Perl-inspired. :)
--
Andrea Faulds
http://ajf.me/

---

## #74683 — Andrea Faulds — 2014-06-01T20:03:32+00:00

URL: https://externals.io/message/74665#74683 · In reply to: #74681

> 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’t have a free character in PHP to use to denote a symbol, so it would have to be two characters. In that case, there’d 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’d either have to start using it everywhere, which won’t happen, or have it just be another syntax for strings, which would be useless as it’s 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 —
> 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’m not entirely sold on :> either, but it’s the best idea I’ve 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/

---

## #74685 — Andrea Faulds — 2014-06-01T20:14:07+00:00

URL: https://externals.io/message/74665#74685

> That's not really "the opposite". IIRC, the => is considered to be "syntactic sugar" for the ",". The quotes are optional in both cases.

Actually you’re right, my bad, however under strict mode you have to use => as bare words are forbidden otherwise.

--
Andrea Faulds
http://ajf.me/

---

## #74688 — Levi Morrison — 2014-06-01T21:15:41+00:00

URL: https://externals.io/message/74665#74688 · In reply to: #74665

> Good evening,
>
> I have created an RFC containing two proposals.

This should be two RFCs then. Two proposals should be two RFCs.

---

## #74689 — Andrea Faulds — 2014-06-01T22:19:43+00:00

URL: https://externals.io/message/74665#74689 · In reply to: #74688

> 
> > […]
> 
> This should be two RFCs then. Two proposals should be two RFCs.

After thinking about it, I’ve split it into two RFCs:

* https://wiki.php.net/rfc/bare_name_array_literal

* https://wiki.php.net/rfc/bare_name_array_dereference

However, for the sake of avoiding fragmentation, I think it would be best not to make two new mailing list threads.

--
Andrea Faulds
http://ajf.me/

---

## #74691 — Nikita Nefedov — 2014-06-02T06:38:55+00:00

URL: https://externals.io/message/74665#74691 · In reply to: #74681

> 
> > […]
>
> 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 —
> 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.

Hi,

Actually Ruby's symbol is like PHP's string. It's immutable and it's  
interned. Unlike Ruby's strings which are mutable. So the question is in  
the syntax only...

---

## #74692 — Derick Rethans — 2014-06-02T08:47:43+00:00

URL: https://externals.io/message/74665#74692 · In reply to: #74665

> 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,

We already voted no for this when discussing the short array syntax. See 
the vote under "Array short syntax" at 
https://wiki.php.net/todo/php54/vote

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #74693 — Ferenc Kovacs — 2014-06-02T08:55:24+00:00

URL: https://externals.io/message/74665#74693 · In reply to: #74667

>
> 
>
> > […]
>
> Yes, but then you’ll get:
>         Notice: Use of undefined constant stringKey - assumed 'stringKey'
> in Command line code on line 1
>
> > […]
>
> Well, we already replaced array() with []. I think it is reasonable to
> consider saving characters in other places. It’s not a *big* priority, no,
> and we shouldn’t do it excessively, but if common cases are cumbersome, we
> should try to deal with them.
>
> Array literals with string keys and dereferencing arrays with string keys
> are extremely common in PHP. So I think this reduction would benefit most
> users, especially those who deal with JSON and the like (which I do a lot
> in my on code), as this makes declaring arrays to be serialised more
> convenient. Also, foobar: just looks nicer than “foobar” =>, especially
> when you have syntax highlighting.
>
>
originally JSON(or what it ended up as JSON) didn't require the keys to be
quoted, but it didn't took too long to bump into a reserved keyword and
realize that it is better to require the keys to be quoted:
https://www.youtube.com/watch?v=-C-JoyNuQJs#3m30s

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #74694 — johannes@schlueters.de — 2014-06-02T08:55:41+00:00

URL: https://externals.io/message/74665#74694 · In reply to: #74665

> 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

---

## #74695 — Arvids Godjuks — 2014-06-02T09:13:28+00:00

URL: https://externals.io/message/74665#74695 · In reply to: #74694

I'm personally against it adding :>
It's just pointles and kind'a looks like an object access.
Not to mention that one time access that deep is normal. but if you are
looping through a lot of data - it's quite an overhead and encoruaging
users to do it that way is just plain wrong to me.

As to the 'stringKey' : 3 - don't realy have anything against it, just the
readability is not that great when you put it in on larger array
definitions. => is very clear about what you are looking at and what it
does and is very visible. So, personaly I would prefer to have just one way
of defining key => value in PHP code.

---

## #74696 — Andrea Faulds — 2014-06-02T10:09:50+00:00

URL: https://externals.io/message/74665#74696 · In reply to: #74692

> We already voted no for this when discussing the short array syntax. See 
> the vote under "Array short syntax" at 
> https://wiki.php.net/todo/php54/vote

That proposal was similar, but not quite the same. That added a : operator that functioned exactly the same as =>. This proposes a : operator that takes a bare name.
—
Andrea Faulds
http://ajf.me/

---

## #74697 — Andrea Faulds — 2014-06-02T10:11:30+00:00

URL: https://externals.io/message/74665#74697 · In reply to: #74695

> I'm personally against it adding :>
> It's just pointles and kind'a looks like an object access.
> Not to mention that one time access that deep is normal. but if you are looping through a lot of data - it's quite an overhead and encoruaging users to do it that way is just plain wrong to me.

I don’t see how deep access is encouraged by :> any more than by ->

--
Andrea Faulds
http://ajf.me/

---

Next page: https://externals.io/message/74665.md?page=2