Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Short array syntax finally in PHP 5.4

svn.php.net

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Short array syntax finally in PHP 5.4

#41

Post by code_duck »

gdulli wrote: post #18

My big complaint about arrays wasn't declaring them. It was the endless array functions you have to use afterwards. array_push array_pop array_slice array_shift array_unshift array_map array_key_exists 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. And this RFC, simple as it is, took 3.5 years to come to fruitio…

The best step forward for PHP, in my opinion, would be to deprecate all of those fake-namespaced functions, and start treating instances of built-in types as objects. This would also be the chance to fix all the 'needle/haystack, haystack/needle?' type inconsistencies.

The older functions could still exist for backwards compatibility, but people who want to write clean OO code could use the new style. $anArray->map(function(){}), $aString->pos('cow'), etc.

This would be a big step for PHP, and bringing the language closer to parity with Ruby and Python. Not sure how it works with eager type coercion, but JavaScript does it somehow.

Re: Short array syntax finally in PHP 5.4

#43

Post by bluekeybox »

ck2 wrote: post #20

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

In the immortal words, I am not even able rightly to apprehend the kind of confusion of ideas that could provoke a question like that.

Slower parsing, really? Is that what you are worrying about?

Re: Short array syntax finally in PHP 5.4

#44

Post by wanderr »

code_duck wrote: post #41
gdulli wrote: post #18

My big complaint about arrays wasn't declaring them. It was the endless array functions you have to use afterwards. array_push array_pop array_slice array_shift array_unshift array_map array_key_exists 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. And this RFC, simple as it is, took 3.5 years to come to fruitio…

The best step forward for PHP, in my opinion, would be to deprecate all of those fake-namespaced functions, and start treating instances of built-in types as objects. This would also be the chance to fix all the 'needle/haystack, haystack/needle?' type inconsistencies. The older functions could still exist for backwards compatibility, but people who want to write clean OO code could use the new style. $anArray->map(f…

Loose typing plus strong OO for basic types is a pretty horrifying cmbination, IMO. What happens if you call $aString->pos() when PHP decides that $aString can be an int because it happens to be holding a string that's composed of numbers?

Re: Short array syntax finally in PHP 5.4

#45

Post by code_duck »

wanderr wrote: post #44
code_duck wrote: post #41

Earlier quoted context omitted.

The best step forward for PHP, in my opinion, would be to deprecate all of those fake-namespaced functions, and start treating instances of built-in types as objects. This would also be the chance to fix all the 'needle/haystack, haystack/needle?' type inconsistencies. The older functions could still exist for backwards compatibility, but people who want to write clean OO code could use the new style. $anArray->map(f…

Loose typing plus strong OO for basic types is a pretty horrifying cmbination, IMO. What happens if you call $aString->pos() when PHP decides that $aString can be an int because it happens to be holding a string that's composed of numbers?

You mean, PHP decides that $aString has to be coerced to an int, not 'can' be, because it's being used in a function that requires an in to make sense? It doesn't matter if it's a string composed of numbers, either - if needed, any string will be coerced regardless of contents, to 0.

What do ECMAScript interpreters do in such a situation?

In the example you gave, this is dependent upon operator precedence. Presumably any method calls are resolved prior to type coercion. This is how PHP and most languages work anyhow, correct? If you do `$this->do_something() + 20`, the method's return value is used. It doesn't try to turn $this into an integer and then call a method upon it. Same for `bcadd($anObj->meth(),34)`. So... I think that isn't a problem.

Re: Short array syntax finally in PHP 5.4

#46

Post by nyordanov »

viraptor wrote: post #33

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.

Right, but wouldn't that make PHP code too good looking? The core devs wouldn't allow it ;)

My only wish is that they implement something that evaluates {} to (object)array(). It would come in handy when used with anonymous functions.

Anyway, I am pleased with the new syntax, but sadly, I have to use 5.2 as most of the time I'm working on WordPress projects...

Re: Short array syntax finally in PHP 5.4

#47

Post by jonathanyc »

Zachhack wrote: post #26
gdulli wrote: post #18

My big complaint about arrays wasn't declaring them. It was the endless array functions you have to use afterwards. array_push array_pop array_slice array_shift array_unshift array_map array_key_exists 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. And this RFC, simple as it is, took 3.5 years to come to fruitio…

I for one would love to see these replaced or complemented by a more OO syntax like: [1,2,3]->push(..) [3,5,6,]->pop(..) [7,8,9]->map(..) etc..

(Un)fortunately, depending on how you look at it, "everything is an object" is left out in PHP. I personally agree with having some non-object values (use one of the Spl* classes if you want something like that).

Re: Short array syntax finally in PHP 5.4

#48

Post by paradox95 »

barredo wrote: post #7

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

I don't see how this will ever be useful. The state "echo boo()[1];" assumes you're only ever going to need that one value from the array. The rest of the array is lost. What if the next line in the code needs index 3 from the array? Now you have to run the function again.

I also don't agree that PHP needs constructors to return $this for the same reason. You need to assign the object to a variable so you can reuse it.

  $a = new Foo()->bar();
In this case if I later want to call another method on the Foo instance I have recreate it.

Re: Short array syntax finally in PHP 5.4

#49

Post by jrockway »

wvenable wrote: post #31
andrewvc wrote: post #14

Earlier quoted context omitted.

Ah yes, I love nothing more than functions on the left side of assignment. Edit: Yes, it is a special form, but its still irregular, and that makes it shitty.

It's a pretty common feature of a lot of languages (Python, Perl, etc) so it's really not that irregular.

It looks more obviously "language feature" in Perl, Python, and JavaScript, though:

   my ($foo, $bar) = f;
   (foo, bar)      = f()
   var [foo, bar]  = f();
Post reply on HN