# RFC: Short syntax for Arrays (redux)

- Thread: https://externals.io/message/52566
- Original archive: https://news-web.php.net/php.internals/52566
- Started by Brian Moon on 2011-05-31T18:42:18+00:00
- Messages: 126
- Page 1 of 6: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/52566.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

---

## #52566 — Brian Moon — 2011-05-31T18:42:18+00:00

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

https://wiki.php.net/rfc/shortsyntaxforarrays

Since this was brought again recently by Rasmus 
(http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where 
several people including Andi chimed in on it and Ilia seemed to reverse 
his thoughts as well (with caveats), I thought I would start a real 
thread about it. The reason the RFC stalled was stated as:

"This patch will not be accepted because slight majority of the core 
developers voted against. Though if you take a accumulated mean between 
core developers and userland votes seems to show the opposite it would 
be irresponsible to submit a patch witch is not supported or maintained 
in the long run."

So, the PHP users want it, but too many PHP core devs did not want it or 
did not see the use of it. From rereading the mailing list archive, most 
had the tone of "I don't see a reason for it." I was in that camp in 
2003 when it first came up. However, with the emergence of JSON and 
systems that use JSON as an interface, this type of syntax would be most 
welcome in the day to day life of a PHP developer.

I would prefer (as Rasmus pointed out) not to start a long discussion 
about it. Primarily I would be curious if anyone on the lists (from the 
RFC wiki page) below would like to change your vote or if you are not 
listed below and would like to be counted, that would be great too.

PHP SVN account holder voters
=============================
Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, 
Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic

Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe 
Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes 
Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel 
Brown, Jochem Maas, Hannes Magnusson, David Coallier


Other voters
============
Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey 
Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric 
Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, 
Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron

Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke


-- 
Brian.
http://brian.moonspot.net

---

## #52567 — Sean Coates — 2011-05-31T18:52:12+00:00

URL: https://externals.io/message/52566#52567 · In reply to: #52566

I'm one of the people who've brought it up on Twitter. Today's discussion seems to have earned some traction, which is a step in the right direction, I believe.

> I would prefer (as Rasmus pointed out) not to start a long discussion about it. Primarily I would be curious if anyone on the lists (from the RFC wiki page) below would like to change your vote or if you are not listed below and would like to be counted, that would be great too.

At risk of turning this into a longer-than-necessary discussion, I believe a new RFC is required at this point. Making [ and ] work as (T_ARRAY, '(') and (')'), respectively is no longer good enough, for the main reason you've pointed out: JSON is becoming ubiquitous; actual first-class JSON would be very valuable to me.

I would be happy to find some time to participate in RFC reform for this subject.

That said:

> PHP SVN account holder voters
> =============================
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic

+1 (sean)

S

---

## #52568 — guilhermeblanco@gmail.com — 2011-05-31T18:53:27+00:00

URL: https://externals.io/message/52566#52568 · In reply to: #52567

+1


> I'm one of the people who've brought it up on Twitter. Today's discussion seems to have earned some traction, which is a step in the right direction, I believe.
>
> > […]
>
> At risk of turning this into a longer-than-necessary discussion, I believe a new RFC is required at this point. Making [ and ] work as (T_ARRAY, '(') and (')'), respectively is no longer good enough, for the main reason you've pointed out: JSON is becoming ubiquitous; actual first-class JSON would be very valuable to me.
>
> I would be happy to find some time to participate in RFC reform for this subject.
>
> That said:
>
> > […]
>
> +1 (sean)
>
> S
>
>
> --
> 
> 
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

---

## #52569 — Philip Olson — 2011-05-31T19:06:01+00:00

URL: https://externals.io/message/52566#52569 · In reply to: #52566

A few notes worth mentioning:

- That RFC moved from fail to 'under discussion' a few weeks ago, although it hasn't been edited
- Most people are now for it, or at least that's the general feeling on IRC (#php.pecl) these past few weeks
- Discussing it is on the 5.4 TODO ( https://wiki.php.net/todo/php54 )

And since I voted against it last time around, here's my take (quoting myself here from the recent 5.4 thread):

"I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or may not) slow adoption, but since other such changes are being made then let's do it. And while explicit code (e.g., array()) is nice, many people are familiar with array shortcuts."

I think the main question is if related features (e.g., inline array slicing) should also be implemented. Once upon a time the $arr{} syntax almost did that.

Regards,
Philip

---

## #52570 — fgm@osinet.fr — 2011-05-31T19:07:54+00:00

URL: https://externals.io/message/52566#52570 · In reply to: #52566

Voting in favor of a short syntax, as a mostly userland dev, seems a  
no-brainer, but both suggested syntaxes and patches are rather unnatural:  
they attempt to mimic JSON syntax, but do not go the whole way.

The second syntax, possibly more natural to PHP devs, might well be more  
trouble than it is worth, though, as it is quite close to the existing  
()-braced format, only with [], thus possibly disturbing new users of the  
language. The first syntax, being more remote from the normal array()  
initializer format, might well be less disturbing. But in that case, it  
might just as well be completely handle a complete JSON initialization  
format, without the need for a `json_decode()`.


Le Tue, 31 May 2011 20:42:18 +0200, Brian Moon <brian@moonspot.net> a  
écrit:

> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus  
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where  
> several people including Andi chimed in on it and Ilia seemed to reverse  
> his thoughts as well (with caveats), I thought I would start a real  
> thread about it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core  
> developers voted against. Though if you take a accumulated mean between  
> core developers and userland votes seems to show the opposite it would  
> be irresponsible to submit a patch witch is not supported or maintained  
> in the long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or  
> did not see the use of it. From rereading the mailing list archive, most  
> had the tone of "I don't see a reason for it." I was in that camp in  
> 2003 when it first came up. However, with the emergence of JSON and  
> systems that use JSON as an interface, this type of syntax would be most  
> welcome in the day to day life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion  
> about it. Primarily I would be curious if anyone on the lists (from the  
> RFC wiki page) below would like to change your vote or if you are not  
> listed below and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =============================
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf,  
> Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe  
> Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes  
> Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel  
> Brown, Jochem Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> ============
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey  
> Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric  
> Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk,  
> Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>


-- 
Utilisant le logiciel de courrier révolutionnaire d'Opera :  
http://www.opera.com/mail/

---

## #52573 — Justin Carmony — 2011-05-31T19:41:30+00:00

URL: https://externals.io/message/52566#52573 · In reply to: #52566

This is my first time posting to the mailing list, been lurking for a little while, but I would like to throw in my thoughts. I've written about the idea of PHP supporting JSON notation on my blog before (http://www.justincarmony.com/blog/2011/04/12/php-itch-to-scratch-object-notation/), and I think it would be beneficial because:

- Frameworks and Libraries are becoming more verbose as they support more modular designs. The more PHP as a language can do to help developers make their frameworks less verbose (like supporting JSON like notations), the happier developers will be. 

- Most developers are familiar with JSON, so the learning curve for this notation would be low.

- While short hand for arrays would be nice, some developers are moving to use objects more over arrays, so a shorthand that supports both arrays and objects would be great.

But the bottom line is I would love to help put together whatever is required for a new RFC, and do anything to help others who don't see the use for the short notation.

Justin Carmony




> https://wiki.php.net/rfc/shortsyntaxforarrays
> 
> Since this was brought again recently by Rasmus (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several people including Andi chimed in on it and Ilia seemed to reverse his thoughts as well (with caveats), I thought I would start a real thread about it. The reason the RFC stalled was stated as:
> 
> "This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run."
> 
> So, the PHP users want it, but too many PHP core devs did not want it or did not see the use of it. From rereading the mailing list archive, most had the tone of "I don't see a reason for it." I was in that camp in 2003 when it first came up. However, with the emergence of JSON and systems that use JSON as an interface, this type of syntax would be most welcome in the day to day life of a PHP developer.
> 
> I would prefer (as Rasmus pointed out) not to start a long discussion about it. Primarily I would be curious if anyone on the lists (from the RFC wiki page) below would like to change your vote or if you are not listed below and would like to be counted, that would be great too.
> 
> PHP SVN account holder voters
> =============================
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
> 
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier
> 
> 
> Other voters
> ============
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron
> 
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
> 
> 
> -- 
> Brian.
> http://brian.moonspot.net

---

## #52574 — Rafael Dohms — 2011-05-31T19:48:27+00:00

URL: https://externals.io/message/52566#52574 · In reply to: #52573

> > […]

i'm a +1, was not present during first vote.


-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br

---

## #52575 — Stas Malyshev — 2011-05-31T20:28:23+00:00

URL: https://externals.io/message/52566#52575 · In reply to: #52567

Hi!

> At risk of turning this into a longer-than-necessary discussion, I
> believe a new RFC is required at this point. Making [ and ] work as
> (T_ARRAY, '(') and (')'), respectively is no longer good enough, for
> the main reason you've pointed out: JSON is becoming ubiquitous;
> actual first-class JSON would be very valuable to me.

It looks appealing, though if you think about security implications, I'm 
not sure it'd be actually as useful as one might think - i.e., you'd 
rarely want to eval() a JSON string, and absent that native JSON may not 
help you much.
That aside, I think [] as array syntax is long overdue and would improve 
PHP readability and compatibility with other dynamic languages.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #52576 — Mike van Riel — 2011-05-31T20:29:40+00:00

URL: https://externals.io/message/52566#52576 · In reply to: #52567

> I'm one of the people who've brought it up on Twitter. Today's discussion seems to have earned some traction, which is a step in the right direction, I believe.
>
> > […]
> At risk of turning this into a longer-than-necessary discussion, I believe a new RFC is required at this point. Making [ and ] work as (T_ARRAY, '(') and (')'), respectively is no longer good enough, for the main reason you've pointed out: JSON is becoming ubiquitous; actual first-class JSON would be very valuable to me.
>
> I would be happy to find some time to participate in RFC reform for this subject.
>
> That said:
+1

---

## #52577 — Sebastian Krebs — 2011-05-31T20:36:27+00:00

URL: https://externals.io/message/52566#52577 · In reply to: #52566

This is (as far as I remember) my first mail on this list and I don't 
really know, how the voting process works. I guess its free4all, so ...

Am 31.05.2011 20:42, schrieb Brian Moon:
>
>
> I would prefer (as Rasmus pointed out) not to start a long discussion
> about it. Primarily I would be curious if anyone on the lists (from the
> RFC wiki page) below would like to change your vote or if you are not
> listed below and would like to be counted, that would be great too.
>
+1

---

## #52578 — Chris Stockton — 2011-05-31T20:53:06+00:00

URL: https://externals.io/message/52566#52578 · In reply to: #52566

Hello,


> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>

I am very much +1 for this. I would also like to note the sooner we
get it in the sooner it can actually be adopted as most hosting
providers are a couple years behind of latest release, so I hope we
can build some momentum this time around and get a solid "feature"
that the user base wants. In addition I think the "Square bracket
array shortcut - keys and values are separated by colons:" is the way
to go.

Thanks,

-Chris

---

## #52579 — Rasmus — 2011-05-31T21:16:39+00:00

URL: https://externals.io/message/52566#52579 · In reply to: #52567

> I'm one of the people who've brought it up on Twitter. Today's discussion seems to have earned some traction, which is a step in the right direction, I believe.
> 
> > […]
> 
> At risk of turning this into a longer-than-necessary discussion, I believe a new RFC is required at this point. Making [ and ] work as (T_ARRAY, '(') and (')'), respectively is no longer good enough, for the main reason you've pointed out: JSON is becoming ubiquitous; actual first-class JSON would be very valuable to me.

The tricky part with going all json is the syntax, specifically the {}'s

But I think it is doable, mostly because this is not valid today:

  $a = true ? { 1 : 2 };

And in json if you have {}'s you have to have a ':' inside.

I have always preferred to "borrow" a familiar syntax from other
languages that the average PHP user is comfortable with instead of
making up a new one.

Stas, I didn't understand your point about eval() and security. What did
you mean?

-Rasmus

---

## #52580 — Stas Malyshev — 2011-05-31T21:25:46+00:00

URL: https://externals.io/message/52566#52580 · In reply to: #52579

Hi!

> Stas, I didn't understand your point about eval() and security. What did
> you mean?

I meant if PHP has JSON syntax as native, e.g. you can say something like:

$a = {"a":"b"};

Then the temptation would be to write something like:

// $json_string is {"a":"b"}
$a = eval($json_string);

just as Javascript programmers sometimes do. That would have the same 
security implications as it has in Javasctipt - somebody could inject 
executable code there, etc. Of course, nobody forces you to do this, but 
the temptation would be there.

Also, with full JSON support it is not entirely clear to me what {"a": 
"b"} would mean - is it an array or an object? In JS, it's definitely an 
object, but in PHP objects are almost never used to store pure state 
without behavior, because we have hashtable arrays, while JS only has 
vector arrays. So here we have some unclear point (which does not happen 
with [] syntax, since with [] it's obvious we're talking about arrays, 
just as in many other languages).
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #52581 — Rasmus — 2011-05-31T21:34:27+00:00

URL: https://externals.io/message/52566#52581 · In reply to: #52580

> Hi!
> 
> > […]
> 
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
> 
> $a = {"a":"b"};
> 
> Then the temptation would be to write something like:
> 
> // $json_string is {"a":"b"}
> $a = eval($json_string);

We could perhaps catch that case. I'm not sure that is a reason to
reject the idea. People who use eval() on user-supplied data are already
lost causes and trying to design for that case is tricky.

> Also, with full JSON support it is not entirely clear to me what {"a":
> "b"} would mean - is it an array or an object? In JS, it's definitely an
> object, but in PHP objects are almost never used to store pure state
> without behavior, because we have hashtable arrays, while JS only has
> vector arrays. So here we have some unclear point (which does not happen
> with [] syntax, since with [] it's obvious we're talking about arrays,
> just as in many other languages).

Right, this is a trickier issue. In order to handle both associative
arrays and objects the PHP notation would need to be along the lines of:

  [ 1,2,3 ] - Scalar array
  [ 'a':1, 'b':2 ] - Associative array
  { 'a':1, 'b':2 } - Stdclass object with properties a and b

of course the middle case is not valid json and then things break down a
bit. If we are going to support full json and then not be completely
compatible, why use the json syntax at all. And not supporting
associative arrays in the syntax is not an option.

-Rasmus

---

## #52582 — Dan Birken — 2011-05-31T21:34:56+00:00

URL: https://externals.io/message/52566#52582 · In reply to: #52580

It is worth noting that point you bring up is one that is present in PHP
currently:

php > print_r(json_decode(json_encode(array('a' => 'b'))));
stdClass Object
(
    [a] => b
)

php > print_r(json_decode(json_encode(array('a', 'b'))));
Array
(
    [0] => a
    [1] => b
)

-Dan

On Tue, May 31, 2011 at 2:25 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
>
>  Stas, I didn't understand your point about eval() and security. What did
> > […]
>
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
>
> $a = {"a":"b"};
>
> Then the temptation would be to write something like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
>
> just as Javascript programmers sometimes do. That would have the same
> security implications as it has in Javasctipt - somebody could inject
> executable code there, etc. Of course, nobody forces you to do this, but the
> temptation would be there.
>
> Also, with full JSON support it is not entirely clear to me what {"a": "b"}
> would mean - is it an array or an object? In JS, it's definitely an object,
> but in PHP objects are almost never used to store pure state without
> behavior, because we have hashtable arrays, while JS only has vector arrays.
> So here we have some unclear point (which does not happen with [] syntax,
> since with [] it's obvious we're talking about arrays, just as in many other
> languages).
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #52583 — Ilia Alshanetsky — 2011-05-31T21:35:39+00:00

URL: https://externals.io/message/52566#52583 · In reply to: #52566

After reviewing the patch (again), I think there is no harm in support
short-array syntax, similar to JSON format:

    $a = [1, 2, 3];
    $b = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];

So, I am changing my previous -1 to +1.


> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core
> developers voted against. Though if you take a accumulated mean between core
> developers and userland votes seems to show the opposite it would be
> irresponsible to submit a patch witch is not supported or maintained in the
> long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or did
> not see the use of it. From rereading the mailing list archive, most had the
> tone of "I don't see a reason for it." I was in that camp in 2003 when it
> first came up. However, with the emergence of JSON and systems that use JSON
> as an interface, this type of syntax would be most welcome in the day to day
> life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
> page) below would like to change your vote or if you are not listed below
> and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =============================
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
> Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> ============
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>
> --
> Brian.
> http://brian.moonspot.net

---

## #52584 — dukeofgaming — 2011-05-31T21:36:35+00:00

URL: https://externals.io/message/52566#52584 · In reply to: #52580

Hi,

I'm glad the topic has been picked up again, but I think there is an
inconsistency in the proposal now that we are talking about being JSON-ish:
JSON describes objects, not arrays. Then, what if "[]" were used for arrays
and "{}" for objects?, so that:

[1,2,3] //array(0=>1, 1=>2, 2=>3)
['one':1, 'two':2, 'three' : 3] // array('one'=>1, 'two'=>2, 'three' => 3)
['one':1, 'two':2, 'three' : 3] // (object)array('one'=>1, 'two'=>2, 'three'
=> 3)

Regards,

David

On Tue, May 31, 2011 at 4:25 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
>
>  Stas, I didn't understand your point about eval() and security. What did
> > […]
>
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
>
> $a = {"a":"b"};
>
> Then the temptation would be to write something like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
>
> just as Javascript programmers sometimes do. That would have the same
> security implications as it has in Javasctipt - somebody could inject
> executable code there, etc. Of course, nobody forces you to do this, but the
> temptation would be there.
>
> Also, with full JSON support it is not entirely clear to me what {"a": "b"}
> would mean - is it an array or an object? In JS, it's definitely an object,
> but in PHP objects are almost never used to store pure state without
> behavior, because we have hashtable arrays, while JS only has vector arrays.
> So here we have some unclear point (which does not happen with [] syntax,
> since with [] it's obvious we're talking about arrays, just as in many other
> languages).
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #52585 — Stas Malyshev — 2011-05-31T21:39:11+00:00

URL: https://externals.io/message/52566#52585 · In reply to: #52582

Hi!

> It is worth noting that point you bring up is one that is present in PHP
> currently:
>
> php > print_r(json_decode(json_encode(array('a' => 'b'))));
> stdClass Object
> (
>      [a] => b
> )

json_decode has an option for that, see php.net/json_decode

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #52586 — Ilia Alshanetsky — 2011-05-31T21:39:20+00:00

URL: https://externals.io/message/52566#52586 · In reply to: #52580

Stas,

Why would you use eval() as opposed to `json_decode()` ?


> Hi!
>
> > […]
>
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
>
> $a = {"a":"b"};
>
> Then the temptation would be to write something like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
>
> just as Javascript programmers sometimes do. That would have the same
> security implications as it has in Javasctipt - somebody could inject
> executable code there, etc. Of course, nobody forces you to do this, but the
> temptation would be there.
>
> Also, with full JSON support it is not entirely clear to me what {"a": "b"}
> would mean - is it an array or an object? In JS, it's definitely an object,
> but in PHP objects are almost never used to store pure state without
> behavior, because we have hashtable arrays, while JS only has vector arrays.
> So here we have some unclear point (which does not happen with [] syntax,
> since with [] it's obvious we're talking about arrays, just as in many other
> languages).
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #52589 — Rasmus — 2011-05-31T21:42:44+00:00

URL: https://externals.io/message/52566#52589 · In reply to: #52582

> It is worth noting that point you bring up is one that is present in PHP
> currently:
> 
> php > print_r(json_decode(json_encode(array('a' => 'b'))));
> stdClass Object
> (
>     [a] => b
> )
> 
> php > print_r(json_decode(json_encode(array('a', 'b'))));
> Array
> (
>     [0] => a
>     [1] => b
> )

Sure, but that makes makes perfect sense, does it not? Javascript does
not have associative arrays. So any non-scalar array has to be mapped to
a Javascript object in order to be represented. When we bring it back we
map a Javascript object to a PHP object, however, there is an optional
argument on `json_decode()` to change that to an associative array if desired.

The point we are making is that this exact inability of the json
notation to distinguish an associative array from an object makes it a
problematic choice for a native syntax in PHP.

-Rasmus

---

## #52588 — Stas Malyshev — 2011-05-31T21:42:46+00:00

URL: https://externals.io/message/52566#52588 · In reply to: #52586

Hi!

> Why would you use eval() as opposed to `json_decode()` ?

I dunno... People do all kinds of things they're not supposed to :) 
E.g., they may want to include() JSON files to benefit from opcode 
caches, etc.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #52590 — Ilia Alshanetsky — 2011-05-31T21:45:54+00:00

URL: https://externals.io/message/52566#52590 · In reply to: #52579

Rasmus,

Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?


> 
> > […]
>
> The tricky part with going all json is the syntax, specifically the {}'s
>
> But I think it is doable, mostly because this is not valid today:
>
>  $a = true ? { 1 : 2 };
>
> And in json if you have {}'s you have to have a ':' inside.
>
> I have always preferred to "borrow" a familiar syntax from other
> languages that the average PHP user is comfortable with instead of
> making up a new one.
>
> Stas, I didn't understand your point about eval() and security. What did
> you mean?
>
> -Rasmus

---

## #52591 — dukeofgaming — 2011-05-31T21:46:28+00:00

URL: https://externals.io/message/52566#52591 · In reply to: #52584

On Tue, May 31, 2011 at 4:36 PM, dukeofgaming <dukeofgaming@gmail.com>wrote:

> Hi,
>
> I'm glad the topic has been picked up again, but I think there is an
> inconsistency in the proposal now that we are talking about being JSON-ish:
> JSON describes objects, not arrays. Then, what if "[]" were used for arrays
> and "{}" for objects?, so that:
>
> [1,2,3] //array(0=>1, 1=>2, 2=>3)
> ['one':1, 'two':2, 'three' : 3] // array('one'=>1, 'two'=>2, 'three' => 3)
> ['one':1, 'two':2, 'three' : 3] // (object)array('one'=>1, 'two'=>2,
> 'three' => 3)
>
>
Err, I meant:

{'one':1, 'two':2, 'three' : 3} // (object)array('one'=>1, 'two'=>2, 'three'
=> 3)

---

## #52592 — Matt Wilson — 2011-05-31T21:47:59+00:00

URL: https://externals.io/message/52566#52592 · In reply to: #52590

Would seem to me a more elegant solution would to just drop the idea of json interoperability and go with something that works for PHP. 

('a'=>'b', 0=>1234) perhaps?



> Rasmus,
> 
> Don't you think having support for both ['a':1, 'b':2] and {'a':1,
> 'b':2} would create confusion?
> 
> 
> > […]

---

## #52593 — Michael Maclean — 2011-05-31T21:52:43+00:00

URL: https://externals.io/message/52566#52593 · In reply to: #52566

> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus

<snip>

I'm all for this, though I would confess to having a preference for the 
second syntax:

$arr = [ 'foo' => 'bar', 'baz' => 'foo' ]

seems to fit better with PHP than the other one, JSON-compatibility aside.

-- 
Cheers,
Michael

---

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