
PHP Short Syntax for Arrays: developers say no. - bpierre
https://wiki.php.net/rfc/shortsyntaxforarrays
======
jpadvo
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._

~~~
ChiperSoft
It's like they don't even _want_ to fix the language.

~~~
jpadvo
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.

~~~
etfb
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.

~~~
jpadvo
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.

------
mgkimsal
_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.

~~~
jasonlotito
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.

~~~
mgkimsal
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.

~~~
jasonlotito
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.

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

------
oinksoft

      Contra
        ...
        Not searchable through search engines
    

That's a ridiculous argument.

~~~
jemfinch
Not when you consider how a large number of PHP programmers "program" on a
day-to-day basis.

~~~
etfb
Can you imagine what PHP would be like if the developers insisted on pandering
to the lowest common denominator like that?

Oh, wait...

~~~
astrodust
Oh no.

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

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

~~~
gdulli
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.

~~~
TamDenholm
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.

~~~
jerf
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.

~~~
louisdefunes
FTFY: pejorative

------
whichdan

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

~~~
mcantelon
The less visual noise the better.

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

------
jinushaun
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().

------
46Bit
Anyone else getting an untrusted SSL Cert error from the link?

~~~
plnewman
Yep, but just remove the 's' from the protocol.

~~~
rll
Or install the cacert root certificate:

<http://www.cacert.org/index.php?id=3>

~~~
sid0
Do you trust CACert enough?

~~~
rll
Moreso than some of the CAs that are trusted by default, yes.

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

~~~
mcantelon
Sure but this seems better:

    
    
        $foo = [
          'bar': TRUE,
          'baz': 'socks'
        ]

~~~
rorrr
It's kind of JSON-wish, so this would make more sense:

    
    
        $bar = [1, 2, 3];
    
        $foo = {
          'bar': TRUE,
          'baz': 'socks'
        };

~~~
z92
For being JSONish it should be

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

where keys are unquoted. The less typing the better.

~~~
swivelmaster
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.

------
lux
I've wanted this for soo long. It's little things like this that make PHP feel
so much clunkier than other scripting languages...

------
mikelbring
Rasmus voted for it!

------
sippndipp
Another fun fact: We're talking about 1 line in zend_language_parser ;-) The
patch is not just complicated.

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

~~~
ahi
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.

~~~
dolinsky
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");

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

~~~
jpadvo
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. ;)

~~~
Zak
_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.

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

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

~~~
udoprog
i gathered the opposite from the conclusion, unless it somehow leaves a window
for another patch

~~~
jasonlotito
<http://markmail.org/message/fx3brcm4ekh645se>

It's being brought forth again for 5.4, and really pushed. Their is a lot of
momentum from the community, and even those who voted against it before are
changing their mind.

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

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

------
jasonlotito
The vote was in 2008. It's being brought up again for 5.4.

~~~
astrodust
The 'goto' statement was apparently much more urgent.

------
voidr
Limited goto good, short syntax for arrays bad? What the hell is
happening....?

------
orijing
Pros: Readable

Cons: Unreadable

What does that even mean?

------
pizza_
This is a vote for consistency. Reasonable array syntax would be out of place
in PHP.

------
tedjdziuba
Re-arranging the deck chairs on the Titanic.

------
samdalton
$confusion = ['pro' : 'readable', 'contra' : 'unreadable']

-edit- beaten to the punch on that one!

