RFC: Short syntax for Arrays (redux)

14 years ago by Sean Coates — view source

unread

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

14 years ago by guilhermeblanco@gmail.com — view source

unread

+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.

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

--

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

14 years ago by Stas Malyshev — view source

unread

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

14 years ago by Mike van Riel — view source

unread

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:
+1

14 years ago by Rasmus — view source

unread

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.

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

14 years ago by Stas Malyshev — view source

unread

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

14 years ago by Rasmus — view source

unread

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);

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

14 years ago by Dan Birken — view source

unread

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.comwrote:

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

14 years ago by Stas Malyshev — view source

unread

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

14 years ago by Rasmus — view source

unread

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

14 years ago by Dan Birken — view source

unread

Yes it does :)

I guess my point was it would be confusing if PHP supported JSON-like
syntax, but json_decode(X) was different from eval(X). So if PHP isn't
going to use JSON syntax (because it doesn't work for assoc arrays), then I
don't think there is much benefit in using almost JSON syntax.

It just seems simpler that:
array(1, 2) equals [1, 2]
array(1 => 2) equals [1 => 2]

-Dan

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

14 years ago by Matt Wilson — view source

unread

Exactly my point. Why try to fudge json into php, instead of just improving php?

Yes it does :)

I guess my point was it would be confusing if PHP supported JSON-like
syntax, but json_decode(X) was different from eval(X). So if PHP isn't
going to use JSON syntax (because it doesn't work for assoc arrays), then I
don't think there is much benefit in using almost JSON syntax.

It just seems simpler that:
array(1, 2) equals [1, 2]
array(1 => 2) equals [1 => 2]

-Dan

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

14 years ago by dukeofgaming — view source

unread

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.comwrote:

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

14 years ago by dukeofgaming — view source

unread

On Tue, May 31, 2011 at 4:36 PM, dukeofgaming dukeofgaming@gmail.comwrote:

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)

14 years ago by Michael Shadle — view source

unread

Forgive me for injecting my $.02 here but what is the original reason
for changing the most basic language syntax to be a little bit
shorter?

Is it hurting anyone to type out "array()" or something?

I think it is silly that "shortening array syntax" is up for
discussion but ensuring Unicode compatibility isn't a higher priority.
Not to mention named parameters in functions. Or Consistent naming for
functions str_* vs str*, needle/haystack ordering, etc. If you're
wanting to augment or change fundamentals of the language why not
clean some stuff up there first?

14 years ago by Rasmus — view source

unread

Forgive me for injecting my $.02 here but what is the original reason
for changing the most basic language syntax to be a little bit
shorter?

Is it hurting anyone to type out "array()" or something?

I think it is silly that "shortening array syntax" is up for
discussion but ensuring Unicode compatibility isn't a higher priority.
Not to mention named parameters in functions. Or Consistent naming for
functions str_* vs str*, needle/haystack ordering, etc. If you're
wanting to augment or change fundamentals of the language why not
clean some stuff up there first?

Because most of those can't be done without breaking millions of lines
of code out there. And a couple of people worked on Unicode for years
and got very little support. That is not a small project. This short
syntax for arrays is probably the most requested PHP feature right now
and we have a working patch that doesn't break any existing code so the
effort involved is minimal. If you have a working patch that solves the
Unicode issues, by all means, show us.

-Rasmus

14 years ago by Philip Olson — view source

unread

Forgive me for injecting my $.02 here but what is the original reason
for changing the most basic language syntax to be a little bit
shorter?

Is it hurting anyone to type out "array()" or something?

I think it is silly that "shortening array syntax" is up for
discussion but ensuring Unicode compatibility isn't a higher priority.
Not to mention named parameters in functions. Or Consistent naming for
functions str_* vs str*, needle/haystack ordering, etc. If you're
wanting to augment or change fundamentals of the language why not
clean some stuff up there first?

Because most of those can't be done without breaking millions of lines
of code out there. And a couple of people worked on Unicode for years
and got very little support. That is not a small project. This short
syntax for arrays is probably the most requested PHP feature right now
and we have a working patch that doesn't break any existing code so the
effort involved is minimal. If you have a working patch that solves the
Unicode issues, by all means, show us.

And because this mailing list thread is about 'short syntax for arrays' and not the other items you mentioned. If you're interested in another topic, or have a proposal, then please do so as a different thread.

Regards,
Philip

14 years ago by Michael Shadle — view source

unread

Because most of those can't be done without breaking millions of lines
of code out there. And a couple of people worked on Unicode for years
and got very little support. That is not a small project. This short
syntax for arrays is probably the most requested PHP feature right now
and we have a working patch that doesn't break any existing code so the
effort involved is minimal. If you have a working patch that solves the
Unicode issues, by all means, show us.

I agree, it would be a break a lot of code. But I'd rather see some
fundamental changes at that level (call it PHP 6, make it not BC with
PHP 5.x or earlier), and remove the cruft and standardize on some of
the slop.

Shorter array syntax seems like an unnecessary addon, will create more
code confusion (now people have to think of two different ways
something is represented), books will become dated overnight (even
moreso than they are now)

I would help with the Unicode project if I could. I am not sure why it
was so tough, but I imagine people infinitely smarter than I am were
working on it. I saw some automated Unicode testing thing that was
running on a php.net server once and it looked like there was over 70%
coverage at that point. I don't see why it's so hard for PHP to get it
going with all the third party libraries out there which could support
it (and why other languages developed in C or C++ can support it as
well)

I don't mean to get off-topic. PHP is my bread and butter, I have
immense respect for you. It just feels like there's things requested
of the language now that are trying to morph the language into
something else. I see blog posts about "10 things PHP needs to have to
be more like Java" - if you want Java, use Java. Stop trying to extend
PHP to do everything for you. It services the majority of websites on
the net and it has done that for years without that crap - and there
is a reason for that.

Making JSON style arrays seems stupid to me. When I look at a PHP
script I expect PHP syntax. Not stolen pieces from a bunch of other
languages (yes, some of it is that way already, but let's not keep the
trend going please?)

14 years ago by Stas Malyshev — view source

unread

Hi!

I agree, it would be a break a lot of code. But I'd rather see some
fundamental changes at that level (call it PHP 6, make it not BC with
PHP 5.x or earlier), and remove the cruft and standardize on some of
the slop.

Fundamental changes means "throw out your production code and start
developing a new one". Guess how many PHP shops with existing code would
be happy to do it. It's nice to rant about how PHP function are
inconsistent and stuff, but no project was seriously impeded by it ever.
At most it is mildly irritating. Huge BC break, on the other hand, would
mean all major apps/libraries/frameworks become instantly not available,
and who knows when they catch up. At this point, you might as well have
a new language.

Shorter array syntax seems like an unnecessary addon, will create more

Since many experienced people are supporting it, I'd think that while it
seems unnecessary to you, it may seem otherwise for them.

I would help with the Unicode project if I could. I am not sure why it
was so tough, but I imagine people infinitely smarter than I am were

Read this (esp. first answer):
http://stackoverflow.com/q/6162484/214196

It's about Perl, but gives you an impression why it is so tough.

Making JSON style arrays seems stupid to me. When I look at a PHP
script I expect PHP syntax. Not stolen pieces from a bunch of other
languages (yes, some of it is that way already, but let's not keep the
trend going please?)

Why not? If the pieces are good, stealing them is good. It's how
progress happens - you "steal" good pieces and add couple of your own,
and hope the result is good enough that somebody else would want to
steal stuff from it :)

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

14 years ago by dukeofgaming — view source

unread

Also, take a peak at this: http://www.phpsadness.com/sad/45

And compare it with this:
http://perldoc.perl.org/perldsc.html#Declaration-of-a-HASH-OF-COMPLEX-RECORDS

Regards,

David Vega

On Wed, Jun 1, 2011 at 12:15 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

I agree, it would be a break a lot of code. But I'd rather see some

fundamental changes at that level (call it PHP 6, make it not BC with
PHP 5.x or earlier), and remove the cruft and standardize on some of
the slop.

Fundamental changes means "throw out your production code and start
developing a new one". Guess how many PHP shops with existing code would be
happy to do it. It's nice to rant about how PHP function are inconsistent
and stuff, but no project was seriously impeded by it ever. At most it is
mildly irritating. Huge BC break, on the other hand, would mean all major
apps/libraries/frameworks become instantly not available, and who knows when
they catch up. At this point, you might as well have a new language.

Shorter array syntax seems like an unnecessary addon, will create more

Since many experienced people are supporting it, I'd think that while it
seems unnecessary to you, it may seem otherwise for them.

I would help with the Unicode project if I could. I am not sure why it

was so tough, but I imagine people infinitely smarter than I am were

Read this (esp. first answer):
http://stackoverflow.com/q/6162484/214196

It's about Perl, but gives you an impression why it is so tough.

Making JSON style arrays seems stupid to me. When I look at a PHP

script I expect PHP syntax. Not stolen pieces from a bunch of other
languages (yes, some of it is that way already, but let's not keep the
trend going please?)

Why not? If the pieces are good, stealing them is good. It's how progress
happens - you "steal" good pieces and add couple of your own, and hope the
result is good enough that somebody else would want to steal stuff from it
:)

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

14 years ago by Michael Shadle — view source

unread

I don't really want to stand on my soapbox any longer, as it's obvious
where the crowd leans on this one, but I need to clarify a couple
points a bit and feel obligated to reply to another.

Fundamental changes means "throw out your production code and start
developing a new one". Guess how many PHP shops with existing code would be
happy to do it. It's nice to rant about how PHP function are inconsistent
and stuff, but no project was seriously impeded by it ever. At most it is
mildly irritating. Huge BC break, on the other hand, would mean all major
apps/libraries/frameworks become instantly not available, and who knows when
they catch up. At this point, you might as well have a new language.

This is understood, but it was a crackpot example. IMHO, adding more
ways to express the same thing in a well-established language is more
or less the same. It's relearning something you thought you already
knew; yes, one breaks BC, but that is why you'd have to classify it a
different major version. I'm done on that one. Like I said, it's a
crackpot example.

Since many experienced people are supporting it, I'd think that while it
seems unnecessary to you, it may seem otherwise for them.

Many experienced people are also against it.

If a handful of "experienced people" decided to go forward with my
crackpot idea above, would you be in support, just because they are?

Also, you're implying that this is a necessary change for these
experienced people. Is there something I am missing that PHP is not
handling currently and requires this necessary change? (No)

Read this (esp. first answer):
http://stackoverflow.com/q/6162484/214196

It's about Perl, but gives you an impression why it is so tough.

I figured it was tough, based on the amount of effort/time people
spent. Sad to see that it seems abandoned though.

Why not? If the pieces are good, stealing them is good. It's how progress
happens - you "steal" good pieces and add couple of your own, and hope the
result is good enough that somebody else would want to steal stuff from it

While a language is maturing, I would probably agree. I consider PHP
quite mature now. I'd say the proof is in the pudding based on the
numbers.

My chief concerns are these:

IMHO, JSON-style syntax is not as readable as PHP array syntax. It's
shorthanding something that is pretty short as well.

Currently, if I want to find an array in code, I can search just for
"array" or "Array" or "=>" or variations thereof. This adds yet
another type of grep I have to run through. One that I am not sure can
be easily accomplished (wouldn't it be matching quite a lot more
because of it's bare nature? Now we've got to look up neat ways to
combine and grep for :?[]{} etc.) Also, now you have coders on the
same project using their personal preference.

If something isn't broken, why fix it? That was the basis on my
original comment about things that actually were underway or brought
up due to issues.

Before I get off my sandbox, and go back to the shadows on the dev
list, someone privately replied to me and said this will help because
it will "its hurting lots of people's eyes (and wrists on the long
term)" - I'm taking that as a joke.

I understand I can use the "long syntax" still. Great. But why
introduce a second one? I can't even read half the Perl I see nowadays
because people have shortcutted so much crap. As I've said PHP is my
bread and butter, please don't make life harder by making syntax
changes that enable developers to be more cryptic code. I'm a
minimalist myself, I like smaller chunks of clean code, but this idea
is unnecessary as nothing is broken. I can only imagine the poor PHP
developers bastardizing this so badly it takes hours to decypher what
they are trying to do.

I have a feeling this is getting adopted either way, but I feel
obligated as a user to ask "wtf?"

mike

14 years ago by dukeofgaming — view source

unread

I don't really want to stand on my soapbox any longer, as it's obvious
where the crowd leans on this one, but I need to clarify a couple
points a bit and feel obligated to reply to another.

On Tue, May 31, 2011 at 10:15 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:

Fundamental changes means "throw out your production code and start
developing a new one". Guess how many PHP shops with existing code would
be
happy to do it. It's nice to rant about how PHP function are inconsistent
and stuff, but no project was seriously impeded by it ever. At most it is
mildly irritating. Huge BC break, on the other hand, would mean all major
apps/libraries/frameworks become instantly not available, and who knows
when
they catch up. At this point, you might as well have a new language.

This is understood, but it was a crackpot example. IMHO, adding more
ways to express the same thing in a well-established language is more
or less the same. It's relearning something you thought you already
knew; yes, one breaks BC, but that is why you'd have to classify it a
different major version. I'm done on that one. Like I said, it's a
crackpot example.

Since many experienced people are supporting it, I'd think that while it
seems unnecessary to you, it may seem otherwise for them.

Many experienced people are also against it.

AFAIK, it was because they didn't want to maintain/implement it. Don't know
if this was before the patch was provided.

If a handful of "experienced people" decided to go forward with my
crackpot idea above, would you be in support, just because they are?

Also, you're implying that this is a necessary change for these
experienced people. Is there something I am missing that PHP is not
handling currently and requires this necessary change? (No)

Read this (esp. first answer):
http://stackoverflow.com/q/6162484/214196

It's about Perl, but gives you an impression why it is so tough.

I figured it was tough, based on the amount of effort/time people
spent. Sad to see that it seems abandoned though.

Why not? If the pieces are good, stealing them is good. It's how progress
happens - you "steal" good pieces and add couple of your own, and hope
the
result is good enough that somebody else would want to steal stuff from
it

While a language is maturing, I would probably agree. I consider PHP
quite mature now. I'd say the proof is in the pudding based on the
numbers.

My chief concerns are these:

IMHO, JSON-style syntax is not as readable as PHP array syntax. It's
shorthanding something that is pretty short as well.

Currently, if I want to find an array in code, I can search just for
"array" or "Array" or "=>" or variations thereof. This adds yet
another type of grep I have to run through. One that I am not sure can
be easily accomplished (wouldn't it be matching quite a lot more
because of it's bare nature? Now we've got to look up neat ways to
combine and grep for :?[]{} etc.) Also, now you have coders on the
same project using their personal preference.

If something isn't broken, why fix it? That was the basis on my
original comment about things that actually were underway or brought
up due to issues.

Before I get off my sandbox, and go back to the shadows on the dev
list, someone privately replied to me and said this will help because
it will "its hurting lots of people's eyes (and wrists on the long
term)" - I'm taking that as a joke.

Weird, I didn't mean to reply privately, must have mistaken the reply to all
button. Anyhow, I did say it tongue-in-cheek, but the shorter syntax is
easier on the eyes for the nested case. Just FTR I'll copy most of my email
here:

Stolen?, why not learned?. Java has great architectural stuff and if wasn't
for other languages (and developers educated on them) we wouldn't have stuff
like exceptions, reflection, and —in the future— traits. You write as if PHP
could not or should not improve, and that is a very wrong attitude to have
IMHO.

The shorter syntaxes are more readable and thus an improvement. You said:

"Is it hurting anyone to type out "array()" or something?"

I say its hurting lots of people's eyes (and wrists on the long term, tsk
tsk). But its not going to be an obligatory syntax, you will always be able
to use "array()" if you enjoy it; personally, I don't, and I don't think the
proposers and supporters enjoy it that much either.

Regards,

David

14 years ago by Stas Malyshev — view source

unread

Hi!

If a handful of "experienced people" decided to go forward with my
crackpot idea above, would you be in support, just because they are?

No, but I wouldn't say that nobody needs it. I'd say it's a bad idea
despite somebody needing it, for reasons so and so.

I figured it was tough, based on the amount of effort/time people
spent. Sad to see that it seems abandoned though.

Well, you know, if somebody has time/energy to pick it up - go ahead.
But people that worked on it felt they are not getting the result they
hoped for, so they cut their losses and moved on. The beauty of open
source is that if anybody wants to pick it up it's still out there.

IMHO, JSON-style syntax is not as readable as PHP array syntax. It's
shorthanding something that is pretty short as well.

That's obviously a matter of taste - I consider it more readable, for
example. For elephant's sake, we're being unfavorably compared to Perl
on readability! :)

But seriously, if I alone felt that, I'd suck it up - as I did when it
failed last time. But this time more people feel that way - so maybe
it's time for a change. People change, experiences change, tastes
change, languages change.

is unnecessary as nothing is broken. I can only imagine the poor PHP
developers bastardizing this so badly it takes hours to decypher what
they are trying to do.

I think while you point on excessive shortcutting is completely valid,
in this example it is not excessive, as [] array syntax is very common
(Perl, Python, Ruby, JS, D, etc.) and recognizable.

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

14 years ago by Ilia Alshanetsky — view source

unread

Stas,

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

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

14 years ago by Stas Malyshev — view source

unread

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

14 years ago by Ilia Alshanetsky — view source

unread

Rasmus,

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

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.

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

14 years ago by Matt Wilson — view source

unread

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?

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.

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

14 years ago by Sean Coates — view source

unread

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

This sounds OK to me, FWIW.

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?

Please, no. Let's implement or augment JSON, not bastardize it.

S

14 years ago by dukeofgaming — view source

unread

Guys, as I said earlier, not even javascript (from javascript object
notation, as in JSON) is 100% interoperable with JSON because single quotes
are valid in javascript and not in json. I say ":" is way more cleaner than
"=>" and it is a good opportunity to adopt it.

14 years ago by Justin Carmony — view source

unread

I agree with this. So the idea would be adding short hand object notation for PHP, inspired by JSON, but we also allow for associative arrays. So:

$object = { 'var1': 'one', 'var2': 'two' }; // for an object
$assoc_array = [ 'var1': 'one', 'var2': 'two' ]; // for an array

// even mix and match

$person = {
'name': 'Justin',
'city': 'Ogden'
'phones' : [
'home': '555-3928',
'work': '555-3922'
]
};

echo $person->phones['home']; // output: 555-3928

The other option is the [] shorthand would create an ArrayObject, so you can interact with the object like an array or object. But I think it is important that we make it possible to allow for array AND object shorthand.

Justin

Guys, as I said earlier, not even javascript (from javascript object
notation, as in JSON) is 100% interoperable with JSON because single quotes
are valid in javascript and not in json. I say ":" is way more cleaner than
"=>" and it is a good opportunity to adopt it.

14 years ago by Rasmus — view source

unread

Rasmus,

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

Not if we present this as native json support in PHP. Then we have to
support the {} version. Other than a couple of grumpy old-timers, I
think we are in agreement that we should add a short array syntax.
Whether we should extend that to also add a short object syntax is a
secondary question.

Just as a data point, I gave a presentation in Mexico a couple of days
ago to a couple of hundred kids where I went over the accepted new
features in 5.4 and also a short list of features under discussion, and
this short array syntax got the most applause by far. It is much harder
to explain traits than this feature.

-Rasmus

14 years ago by Ilia Alshanetsky — view source

unread

Rasmus,

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

Not if we present this as native json support in PHP. Then we have to
support the {} version. Other than a couple of grumpy old-timers, I
think we are in agreement that we should add a short array syntax.
Whether we should extend that to also add a short object syntax is a
secondary question.

I guess if you present it as a native json support in PHP, it probably
would be ok from clarity standpoint. Overloading {} parser should be
doable, but a little trickier than []. The + of the current patch is
that it is very nice and simple.

14 years ago by Philip Olson — view source

unread

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

14 years ago by fgm@osinet.fr — view source

unread

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/

14 years ago by Justin Carmony — view source

unread

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

14 years ago by Rafael Dohms — view source

unread

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.

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

14 years ago by Sebastian Krebs — view source

unread

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

14 years ago by Chris Stockton — view source

unread

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

14 years ago by Ilia Alshanetsky — view source

unread

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

14 years ago by Michael Maclean — view source

unread

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

14 years ago by Lester Caine — view source

unread

Michael Maclean wrote:

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.

Keeping the => does make a lot more sense since it differentiates that PHP CAN
do things here that simply do not work in JSON? This ONLY works with JSON when
one takes the care to avoid associative arrays, and => in my mind has always
been 'associate' ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Gwynne Raskind — view source

unread

+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

--

-- Gwynne

14 years ago by Peter Cowburn — view source

unread

+1 from me to any of the short-form suggestions (JSON or otherwise).

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

14 years ago by Patrick ALLAERT — view source

unread

2011/5/31 Brian Moon brian@moonspot.net:

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

+1 (patrickallaert)
I wasn't present during 1st vote.

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

14 years ago by Ferenc Kovacs — view source

unread

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

+1 for the current patch.

Tyrael

14 years ago by Patrick ALLAERT — view source

unread

2011/5/31 Brian Moon brian@moonspot.net:

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

--

@Zend

Suggestion for the Zend PHP 5.4 Certification:
Which of the following constructs are valid:
$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
$array = [3 => [42], 'foo': array( 'orange' : 'juice'), 'bar' : 'apple'];
$array = [[3] => 42, 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
{$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];}

:)

14 years ago by Arvids Godjuks — view source

unread

Holly crap, god save us from that.

+1 on short syntax (personally I try to avoid it in JS too - I use new
Array() or JSON), but no : please. It's just ridiculous for PHP.

2011/6/1 Patrick ALLAERT patrick.allaert@gmail.com:

2011/5/31 Brian Moon brian@moonspot.net:

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

--

@Zend

Suggestion for the Zend PHP 5.4 Certification:
Which of the following constructs are valid:
$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
$array = [3 => [42], 'foo': array( 'orange' : 'juice'), 'bar' : 'apple'];
$array = [[3] => 42, 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
{$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];}

:)

14 years ago by Gustavo Lopes — view source

unread

Em Tue, 31 May 2011 19:42:18 +0100, Brian Moon brian@moonspot.net
escreveu:

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

-1

I see very little benefit, specially in my keyboard layout, where typing [
and ] requires pressing Alt Gr + 8/9.

Plus, it can cause confusion because [] is currently used for array
dereference.

For instance:

<?php
class A implements ArrayAccess {
function offsetSet($offset, $value) {}
function offsetExists($offset) {}
function offsetUnset($offset) {}
function offsetGet($offset) { var_dump($offset); }
}
$a = new A;
$a[array()];

is much more clear than

$a[[]]

--
Gustavo Lopes

14 years ago by Arvids Godjuks — view source

unread

My personal feel about this is that yes, short arrays are not bad, but
things like

$a = new A;
$a[array()];

just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to learn one, but that
doesn't mean PHP should go that way too (i'm not alien to system
languages, I had some practice with Pascal, Delphi & C some years ago,
just wanted to go the WEB path so migrated to PHP).

If it's not too much, it would be good to avoid such strange
constructs at all, because people are mean and they tend to do bad
things in code.

14 years ago by Marcel Esser — view source

unread

My kneejerk reaction to this, as no one particularly important, is to
not allow mixing those syntaxes.

I looked at the RFC a minute ago, and I read a reference to a parallel
solution to this being named parameters. Which, I think, is not
accurate. The problem with the array() notation is definitely at deep
nesting levels. The fact that arrays as arguments suddenly look nicer is
basically just a bonus. I really just don't want to type array()
twenty-five times in the same data structure.

PS: That is not to say that I wouldn't love named parameters; I would
adore them. I can't count how many times I've thought that a router
would benefit enormously from being able to do that. However, using an
array instead worked fine - and that is cool.

M.

My personal feel about this is that yes, short arrays are not bad, but
things like

$a = new A;
$a[array()];

just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to learn one, but that
doesn't mean PHP should go that way too (i'm not alien to system
languages, I had some practice with Pascal, Delphi& C some years ago,
just wanted to go the WEB path so migrated to PHP).

If it's not too much, it would be good to avoid such strange
constructs at all, because people are mean and they tend to do bad
things in code.

14 years ago by Pierre Joye — view source

unread

can we please (please!) focus on voting on the RFC and avoid an
enumeration of all possible syntax, formats, ideas, trolls&co we had
in the last decade? Simply vote and let us move one.

Thanks for your understanding,

My kneejerk reaction to this, as no one particularly important, is to not
allow mixing those syntaxes.

I looked at the RFC a minute ago, and I read a reference to a parallel
solution to this being named parameters. Which, I think, is not accurate.
The problem with the array() notation is definitely at deep nesting levels.
The fact that arrays as arguments suddenly look nicer is basically just a
bonus. I really just don't want to type array() twenty-five times in the
same data structure.

PS: That is not to say that I wouldn't love named parameters; I would adore
them. I can't count how many times I've thought that a router would benefit
enormously from being able to do that. However, using an array instead
worked fine - and that is cool.

M.

My personal feel about this is that yes, short arrays are not bad, but
things like

$a = new A;
$a[array()];

just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to learn one, but that
doesn't mean PHP should go that way too (i'm not alien to system
languages, I had some practice with Pascal, Delphi& C some years ago,
just wanted to go the WEB path so migrated to PHP).

If it's not too much, it would be good to avoid such strange
constructs at all, because people are mean and they tend to do bad
things in code.

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Pierre Joye — view source

unread

btwr, I did not mean to kill the discussions but it would be awesome
if every participant would read the past discussions about this RFC
and replies accordingly.

Yes, there are alternatives and other needs related to this RFC, but
it is really time to go with it or forget it.

Cheers,

can we please (please!) focus on voting on the RFC and avoid an
enumeration of all possible syntax, formats, ideas, trolls&co we had
in the last decade? Simply vote and let us move one.

Thanks for your understanding,

My kneejerk reaction to this, as no one particularly important, is to not
allow mixing those syntaxes.

I looked at the RFC a minute ago, and I read a reference to a parallel
solution to this being named parameters. Which, I think, is not accurate.
The problem with the array() notation is definitely at deep nesting levels.
The fact that arrays as arguments suddenly look nicer is basically just a
bonus. I really just don't want to type array() twenty-five times in the
same data structure.

PS: That is not to say that I wouldn't love named parameters; I would adore
them. I can't count how many times I've thought that a router would benefit
enormously from being able to do that. However, using an array instead
worked fine - and that is cool.

M.

My personal feel about this is that yes, short arrays are not bad, but
things like

$a = new A;
$a[array()];

just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to learn one, but that
doesn't mean PHP should go that way too (i'm not alien to system
languages, I had some practice with Pascal, Delphi& C some years ago,
just wanted to go the WEB path so migrated to PHP).

If it's not too much, it would be good to avoid such strange
constructs at all, because people are mean and they tend to do bad
things in code.

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Sebastian Bergmann — view source

unread

Am 31.05.2011 20:42, schrieb Brian Moon:

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

-1

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Pierre Joye — view source

unread

pls add your svn handle in the right section:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Am 31.05.2011 20:42, schrieb Brian Moon:

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

-1

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Derick Rethans — view source

unread

pls add your svn handle in the right section:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Voting does not belong on some wiki. It belongs here on the mailinglist.

Derick

14 years ago by David Soria Parra — view source

unread

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

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

+1 from me now after reviewing the discussion and the patch. But I would
like to see ['x' => 2] instead of ['x': 2] as => was always reserved for
assoc in PHP (as mentioned earlier in the thread).

14 years ago by Antony Dovgal — view source

unread

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

I can has vote on this RFC https://wiki.php.net/rfc/shortsyntaxforfunctions ?

--
Wbr,
Antony Dovgal

http://pinba.org - realtime statistics for PHP

14 years ago by Jonathan Wage — view source

unread

+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

--

--
Connect with me on http://twitter.com/jwage http://twitter.com/jwage
and http://about.me/jwage to keep in touch.

14 years ago by Pierre Joye — view source

unread

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Chris Stockton — view source

unread

Hello,

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.

14 years ago by Lester Caine — view source

unread

Chris Stockton wrote:

Reminder: Pls add your votes here:

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

May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.

It would seem some people have not been watching the news?
http://www.php.net/ top news item ...
But it would seem that the 'change password' processes is not being flagged
properly?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Chris Stockton — view source

unread

Hi Lester,

Chris Stockton wrote:

Reminder: Pls add your votes here:

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

May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.

It would seem some people have not been watching the news?
http://www.php.net/ top news item ...
But it would seem that the 'change password' processes is not being flagged
properly?

I did read that a couple months back, reset my password and logged in
numerous times since (I am logged in now). However I am not able to
edit articles anymore (or maybe never could?). Getting that access
would be appreciated.

Thanks,

-Chris

14 years ago by dukeofgaming — view source

unread

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Who is allowed to vote?, are userland votes still going to count?, if so,
how does one qualify as userland voter?.

Best regards,

David Vega

14 years ago by guilhermeblanco@gmail.com — view source

unread

I think the one that is active can be a voter.
Or maybe the ones that have any karma on php environment is considered a voter.

Cheers,

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Who is allowed to vote?, are userland votes still going to count?, if so,
how does one qualify as userland voter?.

Best regards,

David Vega

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

14 years ago by Philip Olson — view source

unread

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Who is allowed to vote?, are userland votes still going to count?, if so,
how does one qualify as userland voter?.

I think the one that is active can be a voter.
Or maybe the ones that have any karma on php environment is considered a voter.

I'm choosing to ignore this voting mechanism because it feels wrong. And besides, this RFC is outdated and still being reviewed for comments. In other words, nobody knows what they are voting on.

Regards,
Philip

14 years ago by dukeofgaming — view source

unread

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

Who is allowed to vote?, are userland votes still going to count?, if
so,
how does one qualify as userland voter?.

I think the one that is active can be a voter.
Or maybe the ones that have any karma on php environment is considered a
voter.

I'm choosing to ignore this voting mechanism because it feels wrong. And
besides, this RFC is outdated and still being reviewed for comments. In
other words, nobody knows what they are voting on.

Regards,
Philip

Yup, it feels rushed. The RFC should be cleaned up and I think this are the
main items:

Ditch ":"
Ditch the JSON topic or open a separate RFC with it
Introduce the "{ }" syntax for objects and change the title

Regards,

David

14 years ago by Pierre Joye — view source

unread

Yup, it feels rushed. The RFC should be cleaned up and I think this are the
main items:

Ditch ":"

Ditch the JSON topic or open a separate RFC with it

Introduce the "{ }" syntax for objects and change the title

Both json and objects are not part of the RFC. It could be added later
or in a new one.

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

David

David who? :)

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Ferenc Kovacs — view source

unread

David

David who? :)

David Vega

14 years ago by Michael Shadle — view source

unread

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Old:
$foo = array('a' => 'b', 'c' => 'd');

More than likely new:
$foo = ['a' => 'b', 'c' => 'd'];

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

Oh, and for anyone desiring a ":" for this new shorthand, why stop at
array shorthand. Why not change this from:
foreach($foo as $key => $val)

To:
foreach($foo as $key: $val)

That would save one character for each array iteration like that.

Also - if we're worried about saving characters and shorthand why not
just remove the "$" language construct? That's a LOT of keystrokes. In
my WordPress install, that's 75,412 characters saved. Versus 6,960
"array(" matches, which would save 34,800 characters.

These were quick examples from a coworker. Just another PHP user who
said "wait why would they make another way to express an array?"

14 years ago by Justin Carmony — view source

unread

To address the soapbox:

Its not just to reduce the five characters at the beginning, but when you have more complex structures as well. There was already a great example shown (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of that. Also, if object support is added (which we need to add to the RFC), you can cut down on a lot more verbose code, especially with objects.

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
};

Characters: 192

Current way:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$person->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

Characters: 229

That is a 37 character difference. But the real driving factor is given PHP's lack of named parameter syntax, passing objects and arrays (or sometimes a mix, depending on the framework) is becoming very popular. So not only do you save some typing just once, but if you use this pattern a lot, you save a lot of typing over your entire project. Also, when dealing with objects, I have to make sure I retype "person" correctly each time. If I don't, I'll get a notice error. But with the new syntax, it'll throw a parsing error so I can know a lot quicker what my issue is.

As for syntax highlighters, IDEs, books, etc all being outdated, first off no one is suggesting to deprecate the array() function. So you will only use this new syntax if you choose to do so. Second, we broke syntax highlighters, IDEs, and so forth when we introduced namespaces, and every IDE and syntax highlighter I used updated very quickly to support them. I'm assuming the IDEs spent a great deal more time adding Namespacing support than it will to support a short syntax for arrays and objects.

PHP has made short syntax for other things, such a if statement short codes. Yet many books don't cover it, since it is one of those things you read in the documentation later and decide "Do I want to use this?" No one is forcing anyone to use (1 == 1 ? true : false) type of if/then logic. The same will work with the new syntax.

My two cents.

Justin

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Old:
$foo = array('a' => 'b', 'c' => 'd');

More than likely new:
$foo = ['a' => 'b', 'c' => 'd'];

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

Oh, and for anyone desiring a ":" for this new shorthand, why stop at
array shorthand. Why not change this from:
foreach($foo as $key => $val)

To:
foreach($foo as $key: $val)

That would save one character for each array iteration like that.

Also - if we're worried about saving characters and shorthand why not
just remove the "$" language construct? That's a LOT of keystrokes. In
my WordPress install, that's 75,412 characters saved. Versus 6,960
"array(" matches, which would save 34,800 characters.

These were quick examples from a coworker. Just another PHP user who
said "wait why would they make another way to express an array?"

14 years ago by Anthony Ferrara — view source

unread

Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.

To me, the array shortcut syntax is pointless. Do you really mean to
tell me that [1, 2] is more readable/easier to understand than
array(1,2)? To me, it's about a wash.

However, the object shortcut syntax is a major win. For example:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$perspn->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->somethingWithNumbers();
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

vs

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
}

Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).

Just my $0.02...

Anthony

To address the soapbox:

Its not just to reduce the five characters at the beginning, but when you have more complex structures as well. There was already a great example shown (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of that. Also, if object support is added (which we need to add to the RFC), you can cut down on a lot more verbose code, especially with objects.

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
};

Characters: 192

Current way:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$person->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

Characters: 229

That is a 37 character difference. But the real driving factor is given PHP's lack of named parameter syntax, passing objects and arrays (or sometimes a mix, depending on the framework) is becoming very popular. So not only do you save some typing just once, but if you use this pattern a lot, you save a lot of typing over your entire project. Also, when dealing with objects, I have to make sure I retype "person" correctly each time. If I don't, I'll get a notice error. But with the new syntax, it'll throw a parsing error so I can know a lot quicker what my issue is.

As for syntax highlighters, IDEs, books, etc all being outdated, first off no one is suggesting to deprecate the array() function. So you will only use this new syntax if you choose to do so. Second, we broke syntax highlighters, IDEs, and so forth when we introduced namespaces, and every IDE and syntax highlighter I used updated very quickly to support them. I'm assuming the IDEs spent a great deal more time adding Namespacing support than it will to support a short syntax for arrays and objects.

PHP has made short syntax for other things, such a if statement short codes. Yet many books don't cover it, since it is one of those things you read in the documentation later and decide "Do I want to use this?" No one is forcing anyone to use (1 == 1 ? true : false) type of if/then logic. The same will work with the new syntax.

My two cents.

Justin

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Old:
$foo = array('a' => 'b', 'c' => 'd');

More than likely new:
$foo = ['a' => 'b', 'c' => 'd'];

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

Oh, and for anyone desiring a ":" for this new shorthand, why stop at
array shorthand. Why not change this from:
foreach($foo as $key => $val)

To:
foreach($foo as $key: $val)

That would save one character for each array iteration like that.

Also - if we're worried about saving characters and shorthand why not
just remove the "$" language construct? That's a LOT of keystrokes. In
my WordPress install, that's 75,412 characters saved. Versus 6,960
"array(" matches, which would save 34,800 characters.

These were quick examples from a coworker. Just another PHP user who
said "wait why would they make another way to express an array?"

14 years ago by Chris Stockton — view source

unread

Hello,

Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.

To me, the array shortcut syntax is pointless. Do you really mean to
tell me that [1, 2] is more readable/easier to understand than
array(1,2)? To me, it's about a wash.

However, the object shortcut syntax is a major win. For example:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$perspn->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->somethingWithNumbers();
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

vs

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
}

Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.

I don't think doing this is a very big deal, even in the case of Array().
$person = (object) [ 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
]

14 years ago by Michael Shadle — view source

unread

First, why not go the opposite way and standardize the syntax - why
not make object() or Object() work like array() or Array()?

$person = object('name' => 'Justin',
   'city' => 'ogden',
   'state' => 'ut',
   'country' => 'usa',
   'favoriteNumbers' => array(4, 12, 37, 42),
   'unluckyNumbers' => array(6, 13, 21),
   'likesPhp' => 'very much so'
);

Then you maintain consistency instead of relying on specific
characters. That makes more sense than trying to make shorthand for
something so basic to the language. I remember moving from Perl to PHP
I remember thinking "what the hell? Everything is a $, how do you make
hashes?"

Secondly,

"Second, we broke syntax highlighters, IDEs, and so forth when we
introduced namespaces"

Don't get me started on namespaces. :)

14 years ago by Sean Coates — view source

unread

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego discussion.

My application is largely JSON-powered. We pass data from back- to front-end via JSON, we interact with MongoDB via the extension (which is an altered JSON-like protocol (arrays instead of objects), but would be a lot more fluent with actual objects—they're just too hard to make in current PHP), and we interface with ElasticSearch. The paste I linked earlier is our primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching; especially when interacting with systems like the ones I've mentioned. There's a huge amount of value in being able to copy JSON out of PHP and into e.g. CURL to make a query to ElasticSearch without worrying that I've accidentally nested one level too deep or shallow, or accidentally mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error.

S

14 years ago by Michael Shadle — view source

unread

This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error.

Why not make your data in JSON and then $foo = json_encode($data) ?

Why try to adopt JSON to PHP, just so it matches another language's format?

You do realize adding JavaScript syntax for arrays will only make that
consistent with JavaScript, otherwise you're still coding PHP with PHP
syntax, functions, etc. for everything else. That argument seems moot.
If you're more comfortable with JavaScript, start developing in node
if that is your cup of tea.

14 years ago by Sean Coates — view source

unread

Why not make your data in JSON and then $foo = json_encode($data) ?

For exactly the same reason people actually use callbacks efficiently, now that they don't have to create_function() them.

S

14 years ago by dukeofgaming — view source

unread

I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you "jsony" object/array with
single quoted strings wont break the code even when its not JSON.

I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even more times:

Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON

JSON even has its own mime type. The idea of JSON as a first-class citizen
is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
put it in a separate RFC and lets decide con the actual RFC. Perhaps the
JSON idea could benefit from autoboxing and a native class?:
https://wiki.php.net/rfc/autoboxing

JSON is a serializarion format, not a data structure, you coud write an
associative array and if PHP knew the way, it could be autointerpreted as
JSON, no need to make PHP code look like JSON. I think that the BEHAVIOR
of arrays/objects as JSON and without the intervention of serialization
functions should be in a separate RFC. There is really no point to make PHP
look like JSON to handle JSON natively .

This JSON matter and short array/object syntax are different issues just the
way "<?=" and "<?" were.

Could someone get Douglas Crockford in here?, rofl.

Regards,

David

14 years ago by John Crenshaw — view source

unread

I don't think anyone cares about JSON for the sake of being perfect JSON, I didn't intend to give that impression. I'm only hoping for something that generally works on par with all the other JSON parsers in the world. In other words something with roughly the same syntax, constraints, and flexibility as the average browser based JavaScript implementation. Making JSON some special totally separate object type would totally miss the point and meaning of any developer writing such code. Yes, JSON is a very specific encoding, but when a developer writes something "jsony", what they mean is "an object/array with the following structure/values", because that is what the encoding really represents.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: dukeofgaming [mailto:dukeofgaming@gmail.com]
Sent: Wednesday, June 01, 2011 6:52 PM
To: Michael Shadle
Cc: Sean Coates; Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you "jsony" object/array with
single quoted strings wont break the code even when its not JSON.

I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even more times:

Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON

JSON even has its own mime type. The idea of JSON as a first-class citizen
is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
put it in a separate RFC and lets decide con the actual RFC. Perhaps the
JSON idea could benefit from autoboxing and a native class?:
https://wiki.php.net/rfc/autoboxing

JSON is a serializarion format, not a data structure, you coud write an
associative array and if PHP knew the way, it could be autointerpreted as
JSON, no need to make PHP code look like JSON. I think that the BEHAVIOR
of arrays/objects as JSON and without the intervention of serialization
functions should be in a separate RFC. There is really no point to make PHP
look like JSON to handle JSON natively .

This JSON matter and short array/object syntax are different issues just the
way "<?=" and "<?" were.

Could someone get Douglas Crockford in here?, rofl.

Regards,

David

14 years ago by Matt Wilson — view source

unread

The issue I have with that is that, regardless of the syntax chosen, even if it meant a 100% inline JSON syntax, you would still (for obvious reasons) need to parse any JSON string into PHP structures. You still have to do json_load($php_or_json_string) or (god have mercy) eval($string). At that point, the only convenience you get from having JSON syntax in php is the situational ability to copy a JSON string directly into your source code.

I just don't think that's worth introducing a new kind of array/object syntax into PHP. I might prefer that syntax (like python) but I don't think it's right for this language.

I don't think anyone cares about JSON for the sake of being perfect JSON, I didn't intend to give that impression. I'm only hoping for something that generally works on par with all the other JSON parsers in the world. In other words something with roughly the same syntax, constraints, and flexibility as the average browser based JavaScript implementation. Making JSON some special totally separate object type would totally miss the point and meaning of any developer writing such code. Yes, JSON is a very specific encoding, but when a developer writes something "jsony", what they mean is "an object/array with the following structure/values", because that is what the encoding really represents.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: dukeofgaming [mailto:dukeofgaming@gmail.com]
Sent: Wednesday, June 01, 2011 6:52 PM
To: Michael Shadle
Cc: Sean Coates; Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you "jsony" object/array with
single quoted strings wont break the code even when its not JSON.

I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even more times:

Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON

JSON even has its own mime type. The idea of JSON as a first-class citizen
is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
put it in a separate RFC and lets decide con the actual RFC. Perhaps the
JSON idea could benefit from autoboxing and a native class?:
https://wiki.php.net/rfc/autoboxing

JSON is a serializarion format, not a data structure, you coud write an
associative array and if PHP knew the way, it could be autointerpreted as
JSON, no need to make PHP code look like JSON. I think that the BEHAVIOR
of arrays/objects as JSON and without the intervention of serialization
functions should be in a separate RFC. There is really no point to make PHP
look like JSON to handle JSON natively .

This JSON matter and short array/object syntax are different issues just the
way "<?=" and "<?" were.

Could someone get Douglas Crockford in here?, rofl.

Regards,

David

14 years ago by Sanford Whiteman — view source

unread

I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.

Then you should stop saying "pure JSON" and "true JSON" constantly!

I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.

OK, that trashes your example, where values were set based on the
result of a PHP function. There is no "par" for JSON parsers running
methods at creation time, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call "JSON."

Yes, JSON is a very specific encoding, but when a developer writes
something "jsony", what they mean is "an object/array with the
following structure/values", because that is what the encoding
really represents.

Not Javascript developers. Maybe jQiddies think that

{'$gt': strtotime('-1 day')}

is "JSONy" more than it is "JS objecty"?

This is like starting from "Wouldn't inline CSVs be great for creating
arrays?" and drifting to "I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!"

Only thing I might generously refer to as being "JSONy," while
provably not being valid JSON, is a string that conforms in every way
except for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled "JankySON" or just not JSON.

-- S.

14 years ago by Eloy Bote Falcon — view source

unread

2011/6/2 Sanford Whiteman swhitemanlistens-software@cypressintegrated.com

I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.

Then you should stop saying "pure JSON" and "true JSON" constantly!

I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.

OK, that trashes your example, where values were set based on the
result of a PHP function. There is no "par" for JSON parsers running
methods at creation time, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call "JSON."

Yes, JSON is a very specific encoding, but when a developer writes
something "jsony", what they mean is "an object/array with the
following structure/values", because that is what the encoding
really represents.

Not Javascript developers. Maybe jQiddies think that

{'$gt': strtotime('-1 day')}

is "JSONy" more than it is "JS objecty"?

This is like starting from "Wouldn't inline CSVs be great for creating
arrays?" and drifting to "I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!"

Only thing I might generously refer to as being "JSONy," while
provably not being valid JSON, is a string that conforms in every way
except for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled "JankySON" or just not JSON.

-- S.

--

-1 to the RFC.
+1 to => against : if the array short syntax it's finally implemented.

I, being a lazy programmer, don't want anymore new syntax to do the same
thing. I don't care if it a) saves me houndred of kaystrokes in the
definition of arrays, or if b) it's more familiar with
put_your_favorite_syntax_here because:

a) I prefer the simple way of this is done this way against this is
done this way or this_another way or this_yet_another way.
b) When another new fancy tendency of encoding appear I don't want to see it
in the core, because another one will appear in the future and then we will
be in the same point, stacking stuff forever or talking about deprecating
the old and breaking BC.

My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.

14 years ago by John Crenshaw — view source

unread

There's no need to be rude. If you can't make your point without attacking people, then you need a better argument.

"JSON" in this case just means a simple object notation using {, [, and :. You know that. Yes, we're all abusing the term, just like we all abuse "AJAX", regardless of the fact that almost nobody ACTUALLY uses XML as the transfer encoding. Who cares? "JSON" is the best word available. Unless you can suggest a better word to differentiate this format from the others (one that isn't designed to insult anyone who disagrees with you) stop fussing about it.

John Crenshaw
Priacta, Inc.

From: Eloy Bote Falcon [mailto:eloybote@gmail.com]
Sent: Thursday, June 02, 2011 3:58 AM
To: Sanford Whiteman
Cc: John Crenshaw; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

2011/6/2 Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com mailto:swhitemanlistens-software@cypressintegrated.com>

I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.
Then you should stop saying "pure JSON" and "true JSON" constantly!

I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.
OK, that trashes your example, where values were set based on the
result of a PHP function. There is no "par" for JSON parsers running
methods at creation time, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call "JSON."

Yes, JSON is a very specific encoding, but when a developer writes
something "jsony", what they mean is "an object/array with the
following structure/values", because that is what the encoding
really represents.
Not Javascript developers. Maybe jQiddies think that

{'$gt': strtotime('-1 day')}

is "JSONy" more than it is "JS objecty"?

This is like starting from "Wouldn't inline CSVs be great for creating
arrays?" and drifting to "I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!"

Only thing I might generously refer to as being "JSONy," while
provably not being valid JSON, is a string that conforms in every way
except for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled "JankySON" or just not JSON.

-- S.

--

-1 to the RFC.
+1 to => against : if the array short syntax it's finally implemented.

I, being a lazy programmer, don't want anymore new syntax to do the same thing. I don't care if it a) saves me houndred of kaystrokes in the definition of arrays, or if b) it's more familiar with put_your_favorite_syntax_here because:

a) I prefer the simple way of this is done this way against this is done this way or this_another way or this_yet_another way.
b) When another new fancy tendency of encoding appear I don't want to see it in the core, because another one will appear in the future and then we will be in the same point, stacking stuff forever or talking about deprecating the old and breaking BC.

My point is: I'm for implementing something that can't be done currently in PHP, but against for implementing another way of doing the same.

14 years ago by Sanford Whiteman — view source

unread

There's no need to be rude. If you can't make your point without
attacking people, then you need a better argument.

If you can't make your point without misusing terms to the point of
making yourself untrustworthy on that level alone, stop trying to
argue.

The "lazy programmer" axiom doesn't apply to terminology.

"JSON" in this case just means a simple object notation using {, [,
and :. You know that.

Nope. I have NEVER heard a knowledgeable developer use "JSON" in this
way. I consider myself a mid-level Javascript developer, so I'm always
learning both formal coding patterns and informal jargon from people
at the expert level -- but I've never heard this. Evidence, please,
for this claim that the term "JSON" is so abused by people who
provably know better.

"JSON" is the best word available.

Give me a break.

JavaScript object literal.

As above, no knowledgeable JS dev refers to

{ name : function(args) }

as actual or informal "JSON."

Unless you can suggest a better word to differentiate this format
from the others (one that isn't designed to insult anyone who
disagrees with you) stop fussing about it.

You explicitly claimed that "any browser will take" your
JSON-with-interpolated-function-return. And you firmly stated you
wanted "par with all the other JSON parsers in the world."

You're saying that, um, "JSON parser" and "JavaScript engine" are
known to be interchangeable?

Please, just... stop. The time taken here could be better spent
reading the JSON and ES-232 specs than making up false "common
knowledge."

-- S.

14 years ago by Eloy Bote Falcon — view source

unread

Oops, it was a mistake. I replied to all rather than to the list, so I
apologize because I wanted to give my opinion in general and not to reply to
anybody in particular.

Regards.

2011/6/2 John Crenshaw johncrenshaw@priacta.com

There’s no need to be rude. If you can’t make your point without attacking
people, then you need a better argument.

“JSON” in this case just means a simple object notation using {, [, and :.
You know that. Yes, we’re all abusing the term, just like we all abuse
“AJAX”, regardless of the fact that almost nobody ACTUALLY uses XML as the
transfer encoding. Who cares? “JSON” is the best word available. Unless you
can suggest a better word to differentiate this format from the others (one
that isn’t designed to insult anyone who disagrees with you) stop fussing
about it.

John Crenshaw

Priacta, Inc.

From: Eloy Bote Falcon [mailto:eloybote@gmail.com]
Sent: Thursday, June 02, 2011 3:58 AM
To: Sanford Whiteman
Cc: John Crenshaw; PHP internals

Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

2011/6/2 Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com

I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.

Then you should stop saying "pure JSON" and "true JSON" constantly!

I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.

OK, that trashes your example, where values were set based on the
result of a PHP function. There is no "par" for JSON parsers running
methods at creation time, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call "JSON."

Yes, JSON is a very specific encoding, but when a developer writes
something "jsony", what they mean is "an object/array with the
following structure/values", because that is what the encoding
really represents.

Not Javascript developers. Maybe jQiddies think that

{'$gt': strtotime('-1 day')}

is "JSONy" more than it is "JS objecty"?

This is like starting from "Wouldn't inline CSVs be great for creating
arrays?" and drifting to "I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!"

Only thing I might generously refer to as being "JSONy," while
provably not being valid JSON, is a string that conforms in every way
except for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled "JankySON" or just not JSON.

-- S.

--

-1 to the RFC.

+1 to => against : if the array short syntax it's finally implemented.

I, being a lazy programmer, don't want anymore new syntax to do the same
thing. I don't care if it a) saves me houndred of kaystrokes in the
definition of arrays, or if b) it's more familiar with
put_your_favorite_syntax_here because:

a) I prefer the simple way of this is done this way against this is
done this way or this_another way or this_yet_another way.

b) When another new fancy tendency of encoding appear I don't want to see
it in the core, because another one will appear in the future and then we
will be in the same point, stacking stuff forever or talking about
deprecating the old and breaking BC.

My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.

14 years ago by Matthew Weier O'Phinney — view source

unread

This is not about saving five characters every time I type array(),
it's about making my systems all work together in a way that's a
little less abstracted, and a lot less prone to error.

Why not make your data in JSON and then $foo = json_encode($data) ?

Why try to adopt JSON to PHP, just so it matches another language's
format?

You do realize adding JavaScript syntax for arrays will only make that
consistent with JavaScript, otherwise you're still coding PHP with PHP
syntax, functions, etc. for everything else. That argument seems moot.
If you're more comfortable with JavaScript, start developing in node
if that is your cup of tea.

JavaScript is not the only target here. Many, many APIs are utilizing
JSON either internally or as the mechanism for communication with other
systems.

Additionally, have you worked with complex data structures, and
attempted to de/serialize to/from PHP? ext/json does fairly well, but
there are many places where it fails, and many gotchas to consider to
ensure things are serialized correctly.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

14 years ago by John Crenshaw — view source

unread

I'm suddenly realizing that the actual need is, in many cases, specific to the development circumstances. When developing heavily against/with other systems that use JSON (like MongoDB, jQuery, various APIs, etc.) the value of true JSON is immeasurable, and anything that isn't JSON would look wrong in that code. On the other hand, something like ZendFramework may likely look better with something that is more internally consistent, (if it even uses the shorter syntax at all) since the primary emphasis of the code is PHP.

What if both syntaxes are allowed (both pure JSON, and the PHP-like => syntax)? Individual projects could gravitate to the format that makes the most sense on a case by case basis.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: Sean Coates [mailto:sean@seancoates.com]
Sent: Wednesday, June 01, 2011 6:09 PM
To: Anthony Ferrara
Cc: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego discussion.

My application is largely JSON-powered. We pass data from back- to front-end via JSON, we interact with MongoDB via the extension (which is an altered JSON-like protocol (arrays instead of objects), but would be a lot more fluent with actual objects-they're just too hard to make in current PHP), and we interface with ElasticSearch. The paste I linked earlier is our primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching; especially when interacting with systems like the ones I've mentioned. There's a huge amount of value in being able to copy JSON out of PHP and into e.g. CURL to make a query to ElasticSearch without worrying that I've accidentally nested one level too deep or shallow, or accidentally mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error.

S

14 years ago by Ferenc Kovacs — view source

unread

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

the whole patch and RFC was about saving a few types of characters.
so I think that some of the "make JSON first class citizen in PHP"
supporters should open a separate RFC with pros and cons, what BC break can
that cause, etc. before we can vote on that.
but I think that this patch and RFC (maybe with the removal of ':', so we
only support '=>') could and should be voted on.
but if we mix the two idea, we will lose both, at least this is what
happened many times on this list.
so please, update the current RFC if needed, and maybe we should restart the
vote.
don't make this into and endless bikeshedding with continuously
throwing loosely related half-baked ideas on top of the discussion.
thanks.

Tyrael

14 years ago by Martin Scotta — view source

unread

Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.

Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.

Martin Scotta

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

S

14 years ago by david.zuelke@bitextender.com — view source

unread

No we can't; I already explained why in another email last night. Copypasta:

json_decode() can deal with Unicode sequences because decodes to UTF-8. That is not possible in a language construct:

What if I do this, in a latin1 encoded file:

$x = {foo: "ä", bar: "\u0123"}

Should that then give mixed encodings? The "ä" in foo in latin1 and the stuff in bar in UTF-8?

And what if I do:

$x = {foo: "ä\u0123"}

I'll either end up with an invalid UTF-8 sequence, or with latin1 character soup.

David

Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.

Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.

Martin Scotta

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

S

14 years ago by Andrei Zmievski — view source

unread

Stop spreading FUD, please.

It's no different than writing json_decode("ä\u0123").

Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
directly in a Latin-1 encoded script is just fine.

-Andrei

On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
david.zuelke@bitextender.com wrote:

No we can't; I already explained why in another email last night. Copypasta:

json_decode() can deal with Unicode sequences because decodes to UTF-8. That is not possible in a language construct:

What if I do this, in a latin1 encoded file:

$x = {foo: "ä", bar: "\u0123"}

Should that then give mixed encodings? The "ä" in foo in latin1 and the stuff in bar in UTF-8?

And what if I do:

$x = {foo: "ä\u0123"}

I'll either end up with an invalid UTF-8 sequence, or with latin1 character soup.

David

Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.

Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.

Martin Scotta

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

S

14 years ago by david.zuelke@bitextender.com — view source

unread

It's not FUD.

It is different from writing json_decode('ä\u0123'), because json_decode() in PHP only accepts UTF-8 encoded input;

Give it a shot:

<?php
$chr = "\xC3\xA4"; // "ä" as UTF-8
var_dump(json_decode('["' . $chr . '\u00e4"]'));
var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
?>

That'll produce:

array(1) {
[0]=>
string(4) "ää"
}
NULL

Understand what the problem is now?

If someone does this in a latin1-encoded file:

<?php $fancyNewArray = {"yay": "ä"}; ?>

Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but cannot be consumed by PHP's json_decode(). And that would be terribly inconsistent behavior.

David

Stop spreading FUD, please.

It's no different than writing json_decode("ä\u0123").

Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
directly in a Latin-1 encoded script is just fine.

-Andrei

On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
david.zuelke@bitextender.com wrote:

No we can't; I already explained why in another email last night. Copypasta:

json_decode() can deal with Unicode sequences because decodes to UTF-8. That is not possible in a language construct:

What if I do this, in a latin1 encoded file:

$x = {foo: "ä", bar: "\u0123"}

Should that then give mixed encodings? The "ä" in foo in latin1 and the stuff in bar in UTF-8?

And what if I do:

$x = {foo: "ä\u0123"}

I'll either end up with an invalid UTF-8 sequence, or with latin1 character soup.

David

Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.

Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.

Martin Scotta

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

S

14 years ago by John Crenshaw — view source

unread

This is a moot point. You wouldn't send that to json_decode. You would send it to json_encode. In other words json_decode({"yay": "ä"}) is totally wrong in the first place, because json_decode requires a string, not an object.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: David Zülke [mailto:david.zuelke@bitextender.com]
Sent: Friday, June 03, 2011 6:11 PM
To: Andrei Zmievski
Cc: Martin Scotta; Sean Coates; Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

It's not FUD.

It is different from writing json_decode('ä\u0123'), because json_decode() in PHP only accepts UTF-8 encoded input;

Give it a shot:

<?php
$chr = "\xC3\xA4"; // "ä" as UTF-8
var_dump(json_decode('["' . $chr . '\u00e4"]'));
var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
?>

That'll produce:

array(1) {
[0]=>
string(4) "ää"
}
NULL

Understand what the problem is now?

If someone does this in a latin1-encoded file:

<?php $fancyNewArray = {"yay": "ä"}; ?>

Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but cannot be consumed by PHP's json_decode(). And that would be terribly inconsistent behavior.

David

Stop spreading FUD, please.

It's no different than writing json_decode("ä\u0123").

Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
directly in a Latin-1 encoded script is just fine.

-Andrei

On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
david.zuelke@bitextender.com wrote:

No we can't; I already explained why in another email last night. Copypasta:

json_decode() can deal with Unicode sequences because decodes to UTF-8. That is not possible in a language construct:

What if I do this, in a latin1 encoded file:

$x = {foo: "ä", bar: "\u0123"}

Should that then give mixed encodings? The "ä" in foo in latin1 and the stuff in bar in UTF-8?

And what if I do:

$x = {foo: "ä\u0123"}

I'll either end up with an invalid UTF-8 sequence, or with latin1 character soup.

David

Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.

Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.

Martin Scotta

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects-they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

S

14 years ago by david.zuelke@bitextender.com — view source

unread

Yes, I know. Then why are you and others demanding that the resulting syntax be fully compatible with JSON so it could be parsed by other JSON parsers? That makes no sense at all. A file with just ["foo"] in it won't be interpreted by PHP; you need at least <?php ?> wrappers and a semicolon, and then you can't just throw it at another JSON parser anymore.

There is absolutely no use case for this, but some people on this thread seem to have some weird dream where they can somehow share code between languages or whatever. Which they can't. Unless they want to start stripping or padding stuff and generating code.

I was pointing out the encoding issue under the assumption that it somehow did make sense, e.g. that you'd have a JSON compatible declaration somewhere in a PHP file, extracted it with, say, a regex, and handed it to PHP's own JSON parser, which might then struggle depending on the encoding of the file.

David

P.S. I guess that also answers Andrei's question regarding whether or not I understood what a parser was or w/e :)

This is a moot point. You wouldn't send that to json_decode. You would send it to json_encode. In other words json_decode({"yay": "ä"}) is totally wrong in the first place, because json_decode requires a string, not an object.

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: David Zülke [mailto:david.zuelke@bitextender.com]
Sent: Friday, June 03, 2011 6:11 PM
To: Andrei Zmievski
Cc: Martin Scotta; Sean Coates; Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

It's not FUD.

It is different from writing json_decode('ä\u0123'), because json_decode() in PHP only accepts UTF-8 encoded input;

Give it a shot:

<?php
$chr = "\xC3\xA4"; // "ä" as UTF-8
var_dump(json_decode('["' . $chr . '\u00e4"]'));
var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
?>

That'll produce:

array(1) {
[0]=>
string(4) "ää"
}
NULL

Understand what the problem is now?

If someone does this in a latin1-encoded file:

<?php $fancyNewArray = {"yay": "ä"}; ?>

Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but cannot be consumed by PHP's json_decode(). And that would be terribly inconsistent behavior.

David

Stop spreading FUD, please.

It's no different than writing json_decode("ä\u0123").

Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
directly in a Latin-1 encoded script is just fine.

-Andrei

On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
david.zuelke@bitextender.com wrote:

No we can't; I already explained why in another email last night. Copypasta:

json_decode() can deal with Unicode sequences because decodes to UTF-8. That is not possible in a language construct:

What if I do this, in a latin1 encoded file:

$x = {foo: "ä", bar: "\u0123"}

Should that then give mixed encodings? The "ä" in foo in latin1 and the stuff in bar in UTF-8?

And what if I do:

$x = {foo: "ä\u0123"}

I'll either end up with an invalid UTF-8 sequence, or with latin1 character soup.

David

Could we first go out with fully JSON compatible version for 5.4?
and then later decide the => stuff based on how that worked.

Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.

Martin Scotta

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects-they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.

S

14 years ago by Andrei Zmievski — view source

unread

On Sat, Jun 4, 2011 at 4:52 AM, David Zülke
david.zuelke@bitextender.com wrote:

Yes, I know. Then why are you and others demanding that the resulting syntax be fully compatible with JSON so it could be parsed by other JSON parsers? That makes no sense at all. A file with just ["foo"] in it won't be interpreted by PHP; you need at least <?php ?> wrappers and a semicolon, and then you can't just throw it at another JSON parser anymore.

I never demanded that anything resembling this. I simply stepped into
this thread because of the encoding argument that ensued.

There is absolutely no use case for this, but some people on this thread seem to have some weird dream where they can somehow share code between languages or whatever. Which they can't. Unless they want to start stripping or padding stuff and generating code.

I was pointing out the encoding issue under the assumption that it somehow did make sense, e.g. that you'd have a JSON compatible declaration somewhere in a PHP file, extracted it with, say, a regex, and handed it to PHP's own JSON parser, which might then struggle depending on the encoding of the file.

My impression was that people just wanted a JSON-like way to construct
arrays and objects. Which does not require using a JSON parser, just
the Zend parser.

-Andrei

14 years ago by John Crenshaw — view source

unread

On Sat, Jun 4, 2011 at 4:52 AM, David Zülke
david.zuelke@bitextender.com wrote:

Yes, I know. Then why are you and others demanding that the resulting syntax be fully compatible with JSON so it could be parsed by other JSON parsers? That makes no sense at all. A file with just ["foo"] in it won't be interpreted by PHP; you need at least <?php ?> wrappers and a semicolon, and then you can't just throw it at another JSON parser anymore.

I don't think anyone was asking for this. I and others have been misunderstood on this point, and there seems to be some confusion about how "other systems" came into this discussion.

The desire is to be able to copy/paste things back and forth and make it work with only minor tweaks. For example, when debugging a query against a system that uses JSON as the standard for communication, it is invaluable to be able to copy the problem query from your code, paste it into whatever administrative interface you have, and replace any variable rvalues with constants. After the problem has been worked out, you can copy from the admin interface, paste back to the code, and restore any variables. If PHP handles an object/array syntax that is roughly similar to JSON, this becomes easy. The more different the syntaxes are, the more painful this becomes, until eventually it really isn't an option at all (which is where we are now).

An example perhaps more familiar to most of us is debugging complex regular expressions. Imagine how impossible this would be if there were no way to copy the regular expression from your code to a web based debugger without rewriting it? Also, consider how frustrating it is sometimes when you paste it back and it still doesn't work, because you forgot to escape your slashes. The more manual translation the programmer has to do, the more impractical these sorts of tools become for debugging.

I know a lot of people on this list have strong feelings about whether other systems should be using JSON as a query language/transfer encoding/whatever else; but, the fact is that they do. These systems are growing more popular, and not going to disappear any time soon, which means that like it or not, developers will need tools and languages that simplify the development and debugging process. This RFC should be considered (among other things) in terms of whether it is helpful to developers using these systems, but not in terms of whether anyone wishes these systems would go away (because they won't).

John Crenshaw
Priacta, Inc.

14 years ago by david.zuelke@bitextender.com — view source

unread

This is a moot point. You wouldn't send that to json_decode. You would send it to json_encode. In other words json_decode({"yay": "ä"}) is totally wrong in the first place, because json_decode requires a string, not an object.

Just to quickly make another point... you couldn't necessarily send this "native JSON" construct you and others dream about to json_encode() just like that either, since json_encode() too only accepts UTF-8 encoded input.

So if you have a latin1-encoded file (still the default in Eclipse on Windows, AFAIK) containing this:

var_dump(json_encode({"foo": "ä"}));

Then you'll end up with

string(12) "{"foo":null}"

Which is of course totally consistent with what happens when you do:

var_dump(json_encode(array("foo" => "ä")));

But try to explain that to the average user who doesn't even know what a character encoding is.

It's just a totally bad idea. PHP is a language where a good number of people still ask questions like "how do I open a new browser window without an address bar in PHP" on forums. And now you want to throw yet another language construct at them that looks like JSON, but doesn't necessarily behave like it even when used with PHP's own JSON functionality, and does not offer any benefit whatsoever other than the ability to copy and paste array and object declarations between PHP and JS code.

David

14 years ago by Andrei Zmievski — view source

unread

On Fri, Jun 3, 2011 at 3:11 PM, David Zülke
david.zuelke@bitextender.com wrote:

It's not FUD.

It is different from writing json_decode('ä\u0123'), because json_decode() in PHP only accepts UTF-8 encoded input;

Give it a shot:

<?php
$chr = "\xC3\xA4"; // "ä" as UTF-8
var_dump(json_decode('["' . $chr . '\u00e4"]'));
var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
?>

That'll produce:

array(1) {
[0]=>
string(4) "ää"
}
NULL

Understand what the problem is now?

If someone does this in a latin1-encoded file:

<?php $fancyNewArray = {"yay": "ä"}; ?>

Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but cannot be consumed by PHP's json_decode(). And that would be terribly inconsistent behavior.

David

Of course I know how json_decode() works, David. My question back to
you is, do you know how a parser works? Because there's no reason to
invoke json_decode() on $fancyNewArray, since it would already be an
object, constructed by the Zend parser. The handling of the characters
in the key/value strings is exactly the same as in normal object
property assignments.

-Andrei

P.S. Stop being so patronizing.

14 years ago by Matthew Weier O'Phinney — view source

unread

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which
is an altered JSON-like protocol (arrays instead of objects), but
would be a lot more fluent with actual objects—they're just too hard
to make in current PHP), and we interface with ElasticSearch. The
paste I linked earlier is our primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP
and into e.g. CURL to make a query to ElasticSearch without worrying
that I've accidentally nested one level too deep or shallow, or
accidentally mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(),
it's about making my systems all work together in a way that's a
little less abstracted, and a lot less prone to error.

applause

Well, said, Sean. Basically, this discussion should be likened to
adding SimpleXML to PHP -- providing tools that make interoperability
with other systems or languages simpler.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

14 years ago by Martin Scotta — view source

unread

Martin Scotta

On Mon, Jun 6, 2011 at 3:03 PM, Matthew Weier O'Phinney <
weierophinney@php.net> wrote:

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here

I don't think anything is officially off the table, unless we forego
discussion.

My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which
is an altered JSON-like protocol (arrays instead of objects), but
would be a lot more fluent with actual objects—they're just too hard
to make in current PHP), and we interface with ElasticSearch. The
paste I linked earlier is our primary ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP
and into e.g. CURL to make a query to ElasticSearch without worrying
that I've accidentally nested one level too deep or shallow, or
accidentally mistranslating my arrays into JSON.

This is not about saving five characters every time I type array(),
it's about making my systems all work together in a way that's a
little less abstracted, and a lot less prone to error.

applause

Well, said, Sean. Basically, this discussion should be likened to
adding SimpleXML to PHP -- providing tools that make interoperability
with other systems or languages simpler.

I don't believe this discution will lead to something.

Core devs don't want to change the langt.
...and linked with the "modern" bundle thread...
if you get this feature in the php version --let's say-- 5.4, it will not
be installed on your shared hosting.

equals) feature not available

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

14 years ago by John Crenshaw — view source

unread

For small linear arrays, neither format is "more readable" but for even mildly complex structures, there is a clear difference. Consider the following Mongo query:

$query = array(
'time'=>array('$and'=>array(
array('$gt'=>strtotime('-1 day')),
array('$lt'=>time()),
)),
'$or'=>array(
array('foo'=>'bar'),
array('hello'=>'world')
)
);

Vs. the JSON form:
$query = {
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
};

Because of the clear readability difference I'll take anything, but JSON would be much better than just an "array shorthand".

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Wednesday, June 01, 2011 5:18 PM
To: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.

To me, the array shortcut syntax is pointless. Do you really mean to
tell me that [1, 2] is more readable/easier to understand than
array(1,2)? To me, it's about a wash.

However, the object shortcut syntax is a major win. For example:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$perspn->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->somethingWithNumbers();
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

vs

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
}

Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).

Just my $0.02...

Anthony

To address the soapbox:

Its not just to reduce the five characters at the beginning, but when you have more complex structures as well. There was already a great example shown (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of that. Also, if object support is added (which we need to add to the RFC), you can cut down on a lot more verbose code, especially with objects.

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
};

Characters: 192

Current way:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$person->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

Characters: 229

That is a 37 character difference. But the real driving factor is given PHP's lack of named parameter syntax, passing objects and arrays (or sometimes a mix, depending on the framework) is becoming very popular. So not only do you save some typing just once, but if you use this pattern a lot, you save a lot of typing over your entire project. Also, when dealing with objects, I have to make sure I retype "person" correctly each time. If I don't, I'll get a notice error. But with the new syntax, it'll throw a parsing error so I can know a lot quicker what my issue is.

As for syntax highlighters, IDEs, books, etc all being outdated, first off no one is suggesting to deprecate the array() function. So you will only use this new syntax if you choose to do so. Second, we broke syntax highlighters, IDEs, and so forth when we introduced namespaces, and every IDE and syntax highlighter I used updated very quickly to support them. I'm assuming the IDEs spent a great deal more time adding Namespacing support than it will to support a short syntax for arrays and objects.

PHP has made short syntax for other things, such a if statement short codes. Yet many books don't cover it, since it is one of those things you read in the documentation later and decide "Do I want to use this?" No one is forcing anyone to use (1 == 1 ? true : false) type of if/then logic. The same will work with the new syntax.

My two cents.

Justin

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Old:
$foo = array('a' => 'b', 'c' => 'd');

More than likely new:
$foo = ['a' => 'b', 'c' => 'd'];

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

Oh, and for anyone desiring a ":" for this new shorthand, why stop at
array shorthand. Why not change this from:
foreach($foo as $key => $val)

To:
foreach($foo as $key: $val)

That would save one character for each array iteration like that.

Also - if we're worried about saving characters and shorthand why not
just remove the "$" language construct? That's a LOT of keystrokes. In
my WordPress install, that's 75,412 characters saved. Versus 6,960
"array(" matches, which would save 34,800 characters.

These were quick examples from a coworker. Just another PHP user who
said "wait why would they make another way to express an array?"

14 years ago by Sanford Whiteman — view source

unread

Vs. the JSON form:
{
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
}

That isn't valid JSON for many different reasons... if you think
that's "pure JSON," you need to spend some time with JSONLint.

If you (and others) mean "Javascript object literal," say it.
(Similarly, if you mean "Javascript," don't say "jQuery" <gags>.)

-- S.

14 years ago by david.zuelke@bitextender.com — view source

unread

Just because the MongoDB developers were stupid enough to build a query language on top of JSON does not mean that JSON or JavaScript object literals need to be supported in PHP. And it wouldn't be possible anyway since JSON allows Unicode escape sequences, and PHP cannot even represent those as it is not aware of runtime encodings.

Besides, outside the use case of json_decode(), stdClass is rarely ever useful, so I don't understand why we're even discussing {} shorthands here. It's not in the RFC either, so good job on focusing on the issue and not diluting the discussion.

Getting back to the RFC: I think it's problematic to have two separate syntaxes for the key/value separator. For consistency's sake, I'd rather just have "=>" but not ":". Just my $0.02.

David

For small linear arrays, neither format is "more readable" but for even mildly complex structures, there is a clear difference. Consider the following Mongo query:

$query = array(
'time'=>array('$and'=>array(
array('$gt'=>strtotime('-1 day')),
array('$lt'=>time()),
)),
'$or'=>array(
array('foo'=>'bar'),
array('hello'=>'world')
)
);

Vs. the JSON form:
$query = {
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
};

Because of the clear readability difference I'll take anything, but JSON would be much better than just an "array shorthand".

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Wednesday, June 01, 2011 5:18 PM
To: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.

To me, the array shortcut syntax is pointless. Do you really mean to
tell me that [1, 2] is more readable/easier to understand than
array(1,2)? To me, it's about a wash.

However, the object shortcut syntax is a major win. For example:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$perspn->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->somethingWithNumbers();
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

vs

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
}

Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).

Just my $0.02...

Anthony

To address the soapbox:

Its not just to reduce the five characters at the beginning, but when you have more complex structures as well. There was already a great example shown (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of that. Also, if object support is added (which we need to add to the RFC), you can cut down on a lot more verbose code, especially with objects.

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
};

Characters: 192

Current way:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$person->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

Characters: 229

That is a 37 character difference. But the real driving factor is given PHP's lack of named parameter syntax, passing objects and arrays (or sometimes a mix, depending on the framework) is becoming very popular. So not only do you save some typing just once, but if you use this pattern a lot, you save a lot of typing over your entire project. Also, when dealing with objects, I have to make sure I retype "person" correctly each time. If I don't, I'll get a notice error. But with the new syntax, it'll throw a parsing error so I can know a lot quicker what my issue is.

As for syntax highlighters, IDEs, books, etc all being outdated, first off no one is suggesting to deprecate the array() function. So you will only use this new syntax if you choose to do so. Second, we broke syntax highlighters, IDEs, and so forth when we introduced namespaces, and every IDE and syntax highlighter I used updated very quickly to support them. I'm assuming the IDEs spent a great deal more time adding Namespacing support than it will to support a short syntax for arrays and objects.

PHP has made short syntax for other things, such a if statement short codes. Yet many books don't cover it, since it is one of those things you read in the documentation later and decide "Do I want to use this?" No one is forcing anyone to use (1 == 1 ? true : false) type of if/then logic. The same will work with the new syntax.

My two cents.

Justin

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Old:
$foo = array('a' => 'b', 'c' => 'd');

More than likely new:
$foo = ['a' => 'b', 'c' => 'd'];

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

Oh, and for anyone desiring a ":" for this new shorthand, why stop at
array shorthand. Why not change this from:
foreach($foo as $key => $val)

To:
foreach($foo as $key: $val)

That would save one character for each array iteration like that.

Also - if we're worried about saving characters and shorthand why not
just remove the "$" language construct? That's a LOT of keystrokes. In
my WordPress install, that's 75,412 characters saved. Versus 6,960
"array(" matches, which would save 34,800 characters.

These were quick examples from a coworker. Just another PHP user who
said "wait why would they make another way to express an array?"

14 years ago by Pierre Joye — view source

unread

hi David,

On Thu, Jun 2, 2011 at 12:47 AM, David Zülke
david.zuelke@bitextender.com wrote:

Just because the MongoDB developers were stupid enough to build a query language on top of JSON

Many of us know that you have a deep and constant hate for MongoDB.
However please do respect the netiquette and every developers here. An
idea may be stupid, not necessary developers. While the idea of a
binary format to transfer data is a good idea, in general.

Thanks for your understanding,

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Derick Rethans — view source

unread

Just because the MongoDB developers were stupid enough to build a
query language on top of JSON does not mean that JSON or JavaScript
object literals need to be supported in PHP.

Can't agree more there.

Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

14 years ago by Chris Stockton — view source

unread

Hello,

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

My desire and perhaps the viewpoint of many others to use ":" over
"=>" has very little to do with typing a extra character. This feature
I have seen brought up on the list time and time again, some 8 years
ago being the first. Just recently more people are in favor of it I'm
sure largely due to the common use and readability of JSON. I
understand this discussion is for "array shorthand syntax.." but I
think really people just want to define their data structures like
they do in JSON, I would hate to see such a common and familiar syntax
be changed just for the sake of principal/familiarity.

The take away from this is simply: I think we would be butchering a
very clean, precise and extremely familiar syntax if we use => just to
be "PHP".

-Chris

14 years ago by John Crenshaw — view source

unread

Spot on. It has nothing to do with extra typing (and that sort of design is part of what ruined Ruby). My fingers move plenty fast and if extra characters make things more safe or more readable, I'll be the first to sign up. In this case, however, the extra characters just make things messy.

The most readable format is pure JSON
The most familiar format is pure JSON (because these same developers are almost certainly already using it in their jQuery code)
The most compact format is pure JSON
The format most consistent with other languages is JSON

John Crenshaw
Priacta, Inc.

-----Original Message-----
From: Chris Stockton [mailto:chrisstocktonaz@gmail.com]
Sent: Wednesday, June 01, 2011 5:23 PM
To: Michael Shadle
Cc: Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Hello,

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

My desire and perhaps the viewpoint of many others to use ":" over
"=>" has very little to do with typing a extra character. This feature
I have seen brought up on the list time and time again, some 8 years
ago being the first. Just recently more people are in favor of it I'm
sure largely due to the common use and readability of JSON. I
understand this discussion is for "array shorthand syntax.." but I
think really people just want to define their data structures like
they do in JSON, I would hate to see such a common and familiar syntax
be changed just for the sake of principal/familiarity.

The take away from this is simply: I think we would be butchering a
very clean, precise and extremely familiar syntax if we use => just to
be "PHP".

-Chris

14 years ago by Pierre Joye — view source

unread

Spot on. It has nothing to do with extra typing (and that sort of design is part of what ruined Ruby). My fingers move plenty fast and if extra characters make things more safe or more readable, I'll be the first to sign up. In this case, however, the extra characters just make things messy.

The most readable format is pure JSON

The most familiar format is pure JSON (because these same developers are almost certainly already using it in their jQuery code)

The most compact format is pure JSON

The format most consistent with other languages is JSON

Not sure which other language you refer to but python, C, perl (using
() instead) uses a very similar format.

To me using json (a serializer format) in code sounds wrong, very
wrong, in the 1st place. What's the next step? Bson? Using JSON in the
code also won't save anyone from any kind of conversions errors from
or to JSON.

This RFC proposed two syntaxes, which can be later extended to object
as well if desired. I would stronlgy suggest to focus on this RFC and
get it sort out (accepted or rejected). If it requires to clarify the
RFC to make the voting easier, then let do it.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Ford — view source

unread

-----Original Message-----
From: John Crenshaw [mailto:johncrenshaw@priacta.com]
Sent: 01 June 2011 23:00

Spot on. It has nothing to do with extra typing (and that sort of
design is part of what ruined Ruby). My fingers move plenty fast and
if extra characters make things more safe or more readable, I'll be
the first to sign up. In this case, however, the extra characters
just make things messy.

The most readable format is pure JSON

Matter of opinion. I don't agree.

The most familiar format is pure JSON (because these same
developers are almost certainly already using it in their jQuery
code)

Also matter of opinion, and of experience. Apart from the fact that
my use of jQuery amounts to a few weeks out of a (mumble)-year
programming career, no I don't use pure JSON for it - Javascript
object literals, yes, but not pure JSON.

The most compact format is pure JSON

Um. Depends. I would tend to write 'a': 'b' in JSON, but 'a'=>'b'
in PHP. But YMMV.

The format most consistent with other languages is JSON

Again, matter of experience. Last time I counted, I'd used upward of
30 different programming languages and dialects, some of which had
very bizarre ways of representing things, and none of which (apart
from Javascript!) used a JSON-like array-literal syntax. And,
actually, I want my PHP arrays to look different from my
Javascript/JSON arrays, especially as I might be looking at both as
part of the same project -- I want a big data structure to scream
"I'm PHP" or "I'm Javascript/JSON" at me, to help trigger my brain
into the right programming mode.

All of this is just IMHO, of course, and probably a lot more than my
regulation 2 pennorth, but there you go.

Cheers!

Mike

Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507 City Campus,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.ford@leedsmet.ac.uk T: +44 113 812 4730

To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

14 years ago by Arvids Godjuks — view source

unread

2011/6/2 Ford, Mike M.Ford@leedsmet.ac.uk:

-----Original Message-----
From: John Crenshaw [mailto:johncrenshaw@priacta.com]
Sent: 01 June 2011 23:00

skip

The format most consistent with other languages is JSON

Again, matter of experience. Last time I counted, I'd used upward of
30 different programming languages and dialects, some of which had
very bizarre ways of representing things, and none of which (apart
from Javascript!) used a JSON-like array-literal syntax. And,
actually, I want my PHP arrays to look different from my
Javascript/JSON arrays, especially as I might be looking at both as
part of the same project -- I want a big data structure to scream
"I'm PHP" or "I'm Javascript/JSON" at me, to help trigger my brain
into the right programming mode.

All of this is just IMHO, of course, and probably a lot more than my
regulation 2 pennorth, but there you go.

Cheers!

Mike

My thinking too. Mixind PHP arrays & JS JSON in one file with same
syntax will be a major headache in the future for many.

14 years ago by Sanford Whiteman — view source

unread

Also matter of opinion, and of experience. Apart from the fact that
my use of jQuery amounts to a few weeks out of a (mumble)-year
programming career, no I don't use pure JSON for it - Javascript
object literals, yes, but not pure JSON.

It's not just you. The claim that people regularly pass JSON strings
within JS frameworks is comical; it would be about as smart as passing
serialized PHP vars between PHP functions.

I want my PHP arrays to look different from my Javascript/JSON
arrays, especially as I might be looking at both as part of the same
project -- I want a big data structure to scream "I'm PHP" or "I'm
Javascript/JSON" at me, to help trigger my brain into the right
programming mode.

+1

-- S.

14 years ago by Ford — view source

unread

-----Original Message-----
From: Michael Shadle [mailto:mike503@gmail.com]
Sent: 01 June 2011 21:37

On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye pierre.php@gmail.com
wrote:

I modified the vote page, pls move your votes to the desired
syntax
(or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Not here. For me, the shorter syntax is simply an order of magnitude
more readable. I really don't care how much typing is involved -- if
I were really that fussed, I'd simply set my editor to expand a nice
short abbreviation (such as "ar", maybe) into array(). In fact, I
might go do that right now, now that I've thought of it....

Cheers!

Mike

Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507 City Campus,
Portland Way, LEEDS, LS1 3HE, United Kingdom
E: m.ford@leedsmet.ac.uk T: +44 113 812 4730

To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

14 years ago by Alain Williams — view source

unread

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Not here. For me, the shorter syntax is simply an order of magnitude
more readable. I really don't care how much typing is involved

+1

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

14 years ago by Pierre Joye — view source

unread

I'm choosing to ignore this voting mechanism because it feels wrong.

We always voted based on php.net accounts (@php.net that is), whether
it is a good thing or not is another question and unrelated to this
RFC (for one, I consider that non php.net people should have a voice,
iirc).

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Philip Olson — view source

unread

I'm choosing to ignore this voting mechanism because it feels wrong.

We always voted based on php.net accounts (@php.net that is), whether
it is a good thing or not is another question and unrelated to this
RFC (for one, I consider that non php.net people should have a voice,
iirc).

But this discussion started off so well with true brain storming and ideas coming to light. People started discussing the pros and cons, people saw and began understanding the different angles, and then some people grew tired and forced a premature vote. Yes it got a little messy, but such is life. --voting.

And besides, it's rare that a tallied vote is required because typically a real consensus can be reached.

Regards,
Philip

14 years ago by Pierre Joye — view source

unread

reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.

Thanks,

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

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Brian Moon — view source

unread

reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.

I don't really care which syntax wins as long as one of them gets rolled in.

Brian.

14 years ago by Pierre Joye — view source

unread

so put +1 on both :D

reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.

I don't really care which syntax wins as long as one of them gets rolled in.

Brian.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Stas Malyshev — view source

unread

Hi!

https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.

Just to be clear on my vote, I'd really like to have [], and I think we
MUST keep => there, but I don't care either way about ':'.

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

14 years ago by Sean Coates — view source

unread

pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.

If people vote on this now, will further discussion about how this SHOULD work be shut down with "we already voted on this"?

S

14 years ago by Pierre Joye — view source

unread

which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.

The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.

Cheers,

pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.

If people vote on this now, will further discussion about how this SHOULD
work be shut down with "we already voted on this"?
S

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Sean Coates — view source

unread

If people vote on this now, will further discussion about how this SHOULD
work be shut down with "we already voted on this"?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.

The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.

I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is "clearly" not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water.

As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP.

S

14 years ago by Philip Olson — view source

unread

If people vote on this now, will further discussion about how this SHOULD
work be shut down with "we already voted on this"?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.

The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.

I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is "clearly" not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water.

As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP.

I share this concern, and it applies to future topics and discussions. I think you creating this RFC would be helpful, and that we as a group should respect the desired timeline for proposing this alternative RFC (I assume over the weekend?).

We won't be forgetting this topic (it feels like people are panicking like we will) so if said alternative isn't available or doesn't gain traction then the current [adjusted] RFC should be implemented.

Regards,
Philip

14 years ago by Pierre Joye — view source

unread

If people vote on this now, will further discussion about how this SHOULD
work be shut down with "we already voted on this"?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.

The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.

I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is "clearly" not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water.

As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP.

You can still vote -1 on this RFC and try to block it. That's the
purpose of the votes. But arguing endlessly why json-like syntax is
better without an alternative RFC and patch won't bring you anywhere.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by dukeofgaming — view source

unread

State the case for JSON in a separate RFC and progress will be made, but I
think there is a fundamental mistake here: serialization formats are the
means for interoperability, not the ends.

The only way I see JSONy syntax would help is if PHP code —with JSONy
syntax— would be parsed by a JSON parser, and I don't think that is likely
to happen... if you want PHP to have a data structure behave like JSON that
is another story.

Add use cases, syntax descriptions, and perhaps a patch for this JSON RFC
and the main argument will be better understood; an RFC will help, visceral
statements and personal attacks, on the other hand, won't, so I bet your
time —and everybody else's— will be better spent in writing an RFC to defend
it.

Regards,

David

If people vote on this now, will further discussion about how this
SHOULD
work be shut down with "we already voted on this"?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.

The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.

I don't see why JSON (or JSON-like, or JavaScript Object Literal, or
whatever the least politically-fired term of the moment) syntax is "clearly"
not an option. I'm considering writing a new RFC that calls for first-class
JSONishy syntax, but I have better things to do if it's already dead in the
water.

As much as I'd like to avoid drawing out this discussion, I think a
premature vote that will be used as a political wedge to shut down all
future syntaxes that don't use T_ARRAY is not in the best interest of PHP.

You can still vote -1 on this RFC and try to block it. That's the
purpose of the votes. But arguing endlessly why json-like syntax is
better without an alternative RFC and patch won't bring you anywhere.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Derick Rethans — view source

unread

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

Still -1.

cheers,
Derick

RFC: Short syntax for Arrays (redux)

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

PHP SVN account holder voters

Why not? If the pieces are good, stealing them is good. It's how progress happens - you "steal" good pieces and add couple of your own, and hope the result is good enough that somebody else would want to steal stuff from it :)

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.

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

-- Lester Caine - G8HFL

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

-- Wbr, Antony Dovgal

PHP SVN account holder voters

Other voters

PHP SVN account holder voters

Other voters

-- Lester Caine - G8HFL

Cheers,

Cheers,

Mike

Mike

Cheers,

Just to be clear on my vote, I'd really like to have [], and I think we MUST keep => there, but I don't care either way about ':'.

Cheers,

Cheers,

Why not? If the pieces are good, stealing them is good. It's how
progress happens - you "steal" good pieces and add couple of your own,
and hope the result is good enough that somebody else would want to
steal stuff from it :)

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.

--
Lester Caine - G8HFL

--
Wbr,
Antony Dovgal

--
Lester Caine - G8HFL

Just to be clear on my vote, I'd really like to have [], and I think we
MUST keep => there, but I don't care either way about ':'.