Short array syntax finally in PHP 5.4

My big complaint about arrays wasn't declaring them. It was the endless array functions you have to use afterwards.<p>array_push<p>array_pop<p>array_slice<p>array_shift<p>array_unshift<p>array_map<p>array_key_exists<p>It kind of feels like they missed the point, saving 5 characters when you declare the array once, ignoring all of the other operations you do afterwards.<p>And this RFC, simple as it is, took 3.5 years to come to fruition.

With the removal of bad legacy features like register_globals, magic_quotes_gpc, and safe_mode combined with new features like array de-referencing and traits, I'm really excited for PHP 5.4. :)<p>For anyone who's curious, here's a list of the changes in 5.4 alpha 1: <a href="http://www.php.net/releases/NEWS_5_4_0_alpha1.txt" rel="nofollow">http://www.php.net/releases/NEWS_5_4_0_alpha1.txt</a>

Now if only when a function returns an array we needn't a variable...<p><pre><code> function boo(){ return array(1,2,3) } echo boo()[1];</code></pre>

Just looked through the RFCs... and I'm a bit surprised noone proposed unification of types yet. It seems a bit silly that the resources, objects, arrays, strings are different types at the language level. They could throw out / reorganise a lot of the randomly named functions this way. Just add the proper methods to the actual types and sort out the (haystack, needle) order, underscores or lack of them, etc.

That's great news, finally we can do<p><pre><code> $a = [1, 2, 3]; </code></pre> and it also will make function calls with named parameters much more readable.<p>Sadly, it will be years before the majority of hosting providers adopt 5.4...

Still strikes me as a useless bit of syntactic sugar. Is it <i>really</i> that much work to write array('foo' =&#62; 'bar')? As far as I can tell, writing ['foo' =&#62; 'bar'] isn't that much shorter in the first place.<p><i>sigh</i> Can the PHP devs focus on the real problems now? <i>cough</i> Unicode anyone? Ridiculously inconsistent naming of string and array functions? The woefully incomplete and useless STL? The lack of OO in arrays and strings?

My complaint about arrays in PHP is warnings for reading a array member that may not exist, such as when reading a form input that might not be there.<p><pre><code> $foo = $_POST["foo"]; </code></pre> Undefined array key! Oh, no! Tragedy! A crime has been committed! Are you kidding? Just set $foo to undefined and let me deal with the consequences, please?

That's good to see, but like many have said, I'd really like to see proper OO stuff like $myArray-&#62;pop();<p>What about short object declaration syntax:<p>$obj = { param:'blah' };<p>PHP already has stdClass, so I doubt it would take much of a parser change to implement that.

While I don't use PHP any more, this is still a massive improvement for those that do. Next on the list: Array and String literals as proper objects!

"Perfection is achieved not when there is nothing more to add, but when there is nothing more to cut off."<p>Adding fancy syntax does not magically transform that crapware to something almost perfect like python3 or ruby (in its way) where these syntactic forms are among foundations of the language and are supported through all basic idioms. ^_^

Looks like they decided NOT to include the scalar type hint. <a href="https://wiki.php.net/todo/php54" rel="nofollow">https://wiki.php.net/todo/php54</a><p>Even better would be bool/float/int/string/func ref type hinting...

What's the release roadmap and dates for 5.4?

$I $wish $they $would $get $rid $of $prefixing $every $variable $with $a $dollar $sign.

So does =&#62; quote the lhs, like Perl? Otherwise, what's the point?

But PHP isn't a transmitted language like javascript, why even bother? It will only make the parser slower?