88 comments

[ 3.8 ms ] story [ 149 ms ] thread
I've been wanting this for a long time, seems like a no brainer to me. It'd be nice to add some of the nice syntactic sugar that other languages have.

Kinda strange that they have both readable and unreadable listed as both pro and con...

I don't think that a concise method of working with arrays should be thought of as syntactic sugar, not if you mean it in a pejorative way.

I found array_map, array_filter, array_key_exists, array_this, array_that painful to write, but never felt that I was gaining any sort of readability for it.

No I meant "syntactic sugar" in a good way, i didnt realise it was a pejorative.

I mean it as per the definition on wikipedia:

  Syntactic sugar is a computer science term that refers to syntax within a programming language that is designed to make things easier to read or to express, while alternative ways of expressing them exist.
It is not generally perjorative. Some people interpret it as automatically perjorative, feeling that any syntactic sugar must necessarily carry costs in excess of benefits, but they are in the minority. Sizable minority, but minority.

Concentrations of people who dislike all syntax sugar can be found in the Forth community and concatenative languages in general, Lisp, and to a lesser extent, in the Haskell community. People who think syntax sugar is the answer to everything can be found in the Perl 5 community, and Perl 6 is arguably syntax sugar spun into cotton candy, hardened, and used to build a glorious gossamer castle in the sky, which they are currently working on landing. I have taken this metaphor too far.

Wouldn't it be nice if PHP arrays acted as objects and all of those functions were methods?

$newArray = $array->map("function_name");

Not gonna happen, but would be nice. Any extensions doing this?

You could write that if you wanted, using __call, would be like 10 lines of code or something.
Php arrays don't act as objects and have no methods, so I'm not sure what you are suggesting.
You can create an object that implements the ArrayAccess interface, but it doesn't extend the native array object in the traditional sense.
The pro/cons are arguments extracted from the mailing list. So the guys on the pro side said it was readable, the guys on the contra side said unreadable.

I think it would have been a nice addition...

Guess this just means what's readable to one person is not necessarily readable to another.
$confusion = ['pro' : 'readable', 'contra' : 'unreadable']

-edit- beaten to the punch on that one!

  Contra
    ...
    Not searchable through search engines
That's a ridiculous argument.
I think "search engines" might be a little misleading, it's not readily grepable locally either.
But that is common to most languages. Arrays are something fundamental enough to warrant a place in language syntax.
> That's a ridiculous argument.

Considering how widely taught (and self-taught) PHP is, I think that's pretty important, if only from a business perspective―if people don't learn your language, they don't buy your licensed books, and they don't need your technical support because they never built anything with it.

I've used PHP for ~12 years and never found myself searching for something involving an instance of array syntax.
Not when you consider how a large number of PHP programmers "program" on a day-to-day basis.
Can you imagine what PHP would be like if the developers insisted on pandering to the lowest common denominator like that?

Oh, wait...

Well, python or javascript does not suffer from this, does it? And, I cant, actually, think of any case where code search would require "Array" term.

On the second thought - if PHP would at last consider converting or storing everyhting as an object ("".length or [].walk()), this would cause a problem. Still, see my first sentence.

Not being SEO friendly is an interesting argument. While learning Python, when things like list comprehensions came up in code I was reading, it was very hard for me to figure out how it worked when I couldn't Google the syntax.
I've always wanted a search engine that is optimized for searching for code embedded in web pages. AFAIK google code search isn't really an option because it only searches through code, not through blog posts, stack overflow, and other pages with code in them.

As far as language design goes though, I'd rather use a language that's optimized for writing code than for searching for it :).

You can't search for -1 either. Are they going to switch to negate_number(ONE, true) for people who haven't learned that syntax?

(The "true" causes the value to be returned rather than printed, obviously.)

SEO driven language design. Now I've seen everything.

    $a1 = [1, 2, 3];
    $b1 = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];
    $b2 = ['foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon'];

    $a1 = array(1, 2, 3);
    $b1 = array('foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon');
It would be a nice change to have, but the syntax isn't -that- much better. A compromise might be:

    $b1 = array('foo': 'orange', 'bar': 'apple', 'baz': 'lemon');
But even then, you only save two characters per key:value.
The less visual noise the better.
I've wanted this for soo long. It's little things like this that make PHP feel so much clunkier than other scripting languages...
I'm not sure this is entirely accurate, last time it was voted on the dev list it was narrowly defeated.

The topic was then resurrected about implementing in the 5.4 release and the objections didn't seem to be as strong this time around.

So the rejected status doesn't mean that it won't happen in 5.4 just that that was the previous status of the changes.

This is a vote for consistency. Reasonable array syntax would be out of place in PHP.
Why try to make PHP more readable? Just use another language.

PHP, like C++, is a big industry dinosaur that can't and won't change.

In my opinion, the best think you could do is create a new language which compiles to PHP. I.e. A coffeescript for PHP. You don't have to "vote" and get stupid arguments against; you don't have to be backward compatible; and you only have great programmers in that project since crappy ones will just continue to use their 1500 lines unmaintainable functions anyway.

But why not make it more readable? The patch exists - all it would take is for it to be accepted.

And there are a ton of people who can't justify the switching costs of moving to a different language. And true, a lot of us aren't great programmers. So?

Better tools help. And it's perfectly okay to build and improve tools that regular people will use. Even if they won't be creating the Mona Webapp. ;)

Why not make it more readable? Because I feel like every attempt made to improve PHP are refused by the community.
And it's perfectly okay to build and improve tools that regular people will use.

It is, unfortunately PHP resists changes that most of the rest of us consider improvements. I think at this point we might be better served by putting our efforts in to replacing PHP rather than improving it. The replacement need not be the ultimate web language, but should try to be a good language while maintaining a low barrier to entry.

> coffeescript for PHP

Make this happen please. I can't think of a more deserving language and it'd make my day job a lot nicer.

This does not seem reasonable. I mean that literally -- this feels more like a choice driven by culture than by reason.

The cons seem nowhere near strong enough to counter the fact that the overwhelming majority of users want this syntax, and have been asking for it for years.

It's like they don't even _want_ to fix the language.
I catch myself feeling that way, too, but it is uncharitable and inaccurate. They do work a lot of work on developing the language. The issue is that sometimes their idea of what is should be differs from the idea that most people have.
I don't think it's possible to be too uncharitable about the developers of PHP. Courtesy demands that we give them the benefit of the doubt; but by this stage there is very little doubt left, so very little benefit as well.
the language they built and let everyone in the world use for free powers sites from wikileaks to whitehouse.gov, and its simplicity allowed a lot of non-programmers to write working code and sometimes even start new careers. so it is possible to be too uncharitable about them.

that decision, though, is unfortunate IMHO. esp seeing that the userland votes are overwhelmingly pro while the devs are con.

If courtesy means giving undeserved benefit of the doubt, I'm all for discourtesy. This is about rational discourse.

The statement that "It's like they don't even _want_ to fix the language" is inaccurate. It does not relate to the state of things in the real world.

Accusing the developers of some warped intent to keep it in a broken state is an understandable expression of frustration, but it does nothing to advance our discussion and contributes to a misunderstanding of the situation.

I still hold a grudge against them for disabling short tags by default.

Who decided that "<?php echo $variable;?>" is better than "<?=$variable ?>". I think one of their main arguments was that it could conflict with XML / XHTML parsers, but the people who want to parse php files using XHTML parsers are probably in the minority.

> and have been asking for it for years.

Which is why it's being brought up again for 5.4, since this vote took place in 2008.

I really don't see the issue here.

Maybe it's too much like JavaScript and Ruby and...well, it is kind of a long list.
Whenever I stop coding PHP for a while and return to it, the lack of short array syntax always blows up in my face. I waste a lot of time debugging to just find that arrays need to be initialised with array().
I'm of the opinion you should be writing your PHP in a readable fashion similar to this:

   $foo = array(
      'bar' => TRUE,
      'baz' => 'socks'
   )
(pretend you also have proper tabs as well)
Sure but this seems better:

    $foo = [
      'bar': TRUE,
      'baz': 'socks'
    ]
It's kind of JSON-wish, so this would make more sense:

    $bar = [1, 2, 3];

    $foo = {
      'bar': TRUE,
      'baz': 'socks'
    };
This is more perlish, with the exception of the map delimiter. If you proposed => it would be identical to perl.
Almost, but Perl's => also auto-quotes barewords (and only barewords) on the left hand side, so foo => 23 is identical to "foo" => 23.
What would be your syntax when you mix them? Which is perfectly legal to do:

  array(1, 'bar' => TRUE, 3, 'baz' => 'socks');
But I do like this syntax idea.
IIRC in PHP every array is internally a hash (ie "associative array"), so $bar is {0:1, 1:2, 2:3} in any case?
For being JSONish it should be

$foo = { bar: TRUE, baz: 'socks' };

where keys are unquoted. The less typing the better.

However, PHP allows me to do this:

$keyName = "bar"; $array = array($keyName => "baz");

So in that instance it makes sense to force people to quote their keys. Also, bar or baz could be constants.

That's against the spec. json_decode() will not even decode this.

http://www.json.org/

I know some browsers allow it, but it's not true JSON.

It's been a long time since I did any PHP, but are trailing commas illegal? Normally, it seems like languages follow one of these two patterns, depending on whether their syntax allows extraneous commas or not:

    foo = [
      'first',
      'second',
      'third',
      ]
or

    foo = [ 'first'
          , 'second'
          , 'third'
          ]
The difference between those two examples and yours being that when you want to add a new entry, you only have to edit the line of the entry, rather than having to edit the line before the entry (to put in the comma) as well as the line that you care about. Just an idle question, really.

EDIT: pull unnecessary commentary

No, trailing commas are not illegal. It's actually preferred.

$a = array(1,2,3,); works just fine.

Anyone else getting an untrusted SSL Cert error from the link?
Yep, but just remove the 's' from the protocol.
(comment deleted)
As you'd know if you'd tried it, it then redirects back to the https version - or at least FF & Chrome do, too late to actually check the headers.
This is why I stopped reading the dev mailing list. It was too frustrating to see (IMO) awesome features and suggestions constantly swatted down for (again, IMO) stupid reasons. Not searchable through search engines? Give me a break! I didn't know I was supposed to be writing code for Google. There are _so many_ higher priorities.

I think PHP is going to remain all but stagnant until there is a sea change in the core developers. I'm not sure what their true motives are... laziness? underlying dislike for the language? Whatever it is, all they seem to do is swat down every request, even when (as is the case here) the users are _begging_ for it.

It's like if they can come up with any reason at all not to do it, then they don't. "We already use square brackets for other stuff." Give me a f--king break.

Strange that the legendary PHP developers taste for good design did not won this time...

It's a shame that PHP does not get better as a language, as from the point of view of deployment and "get things done now" is great.

Note that the feature is under discussion for 5.4 and not rejected. Chances are actually extremely good that it will be in 5.4 in some form.
i gathered the opposite from the conclusion, unless it somehow leaves a window for another patch
I think the "vote" recorded in the link is from a long time ago. Looking at the php.internals mailing list from today, this is what Rasmus is saying:

"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." (http://news.php.net/php.internals/52597)

I've just spent a while reading the most recent of the discussion threads linked from there, and they're just further examples of the hostile and insular communities that form around far too many open source projects. Frustrating to read, painful to participate in.

http://markmail.org/message/4brot4f6kthjfzse

I would give up hope for the ability to have a short syntax for arrays (or lots of other syntactical pleasantries) if the core team would please finally implement named arguments.
Could you explain what you mean by this?

edit: ahh, found it. Knew what it was, but not what it was called: http://en.wikipedia.org/wiki/Keyword_argument

Would definitely be a solution to PHP's ridiculous argument ordering inconsistencies.

Yeah, keyword arguments/named parameters.

The most common way that we get to implement (hack) it now is by using an associative array, which then hides parameters in the implementation of the method as opposed to exposing it in the interface which helps both with reading someone elses code as well as provides for parameter initialization and type hinting (which assoc arrays remove).

I agree with you about argument inconsistencies, and named parameters would help with that, but it even goes beyond that, e.g. how many times have you seen this:

  function foo($bar = true, $baz = 5, $qux = "change me"){ ... }

  foo(true,5,"this is what i wanted to change");
when all you should have to do is:

  foo(qux="this is what i wanted to change");
Few people asked for, or even wanted GOTO, yet that seemed to make it through with flying colors. When people would argue against it, the rationale was "well, you don't have to use it!"

Why does the same criteria not apply to short array syntax? If you don't want to use it, don't use it, but hundreds of thousands of other people likely do want it.

FWIW, I first remember hearing about this in 2003/2004, and at that time I was against it for most of the same reasons I've read in opposition to adding it. Working outside of PHP for some time, I've come to realize the shortsightedness I labored under, and would fully love to have this.

I'm not 100% sure the votes on that page are from May 2011 - it's hard to tell for sure.

The votes are old. The discussion has been raised again for 5.4 ( http://markmail.org/message/fx3brcm4ekh645se )

goto is a limited goto, and the reasoning for it's inclusion makes sense when you consider the other forms of limited goto already in place (breaks, cases, try/catches). It's not an unlimited goto.

The wiki page would have diffused this entire post if it had the dates of the votes on it :)

I understand GOTO, but the reaction to people who thought it was a bad idea was "don't use it!", ignoring the fact that whether we use it or not, we have to deal with other peoples' code that do use it.

Yeah, but even the few people who do use it, it's implementation is limited, solving problems that would otherwise require excess code.

The people shouting "don't use it!" are thinking of a limitless goto. It's a shame, but not surprising really.

The vote was in 2008. It's being brought up again for 5.4.
The 'goto' statement was apparently much more urgent.
It was me who wrote that proposal 3y ago. Everyone who is still doing PHP, do whatever you want. Everyone who had left for Ruby or JS - let them - they just don't want.
Re-arranging the deck chairs on the Titanic.
Another fun fact: We're talking about 1 line in zend_language_parser ;-) The patch is not just complicated.
Pros: Readable

Cons: Unreadable

What does that even mean?