6 ms·

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_s

by gdulli 15y ago

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

ryanb 15y ago
agreed. this is one of my pet peeves with PHP also.
robryan 15y ago
Hard to say that it is simple unless you know the internals.
- vmind 15y ago
  2 lines in the parser: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_parser.y?r1=313094&r2=313641 http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_langua... The RFC (https://wiki.php.net/rfc/shortsyntaxforarrays https://wiki.php.net/rfc/shortsyntaxforarrays) was actually rejected by the developers, I think it's only really been put in to appease large userland pressure. Find it rather amusing that a 2 change to the parser for an alias would be rejected on 'maintainability' grounds.
  - birken 15y ago
    The voting results on the RFC page is from 2008 when it was rejected. The recent vote that decided its inclusion was here: https://wiki.php.net/todo/php54/vote https://wiki.php.net/todo/php54/vote. I think it had pretty solid support from core developers as well as userland people this time around.
- zakovyrya 15y ago
  And why should everyone know or care about language internals?
  - JeremyBanks 15y ago
    If someone is making a statement about how "simple" something is to implement, they should know what they're talking about, no?
Zachhack 15y ago
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..
- jonathanyc 15y ago
  (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).
Tharkun 15y ago
Not to mention the wonderfully inconsistent count() and sort(). Pah.
code_duck 15y ago
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.
- wanderr 15y ago
  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?
  - code_duck 15y ago
    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.
  - fooyc 15y ago
    PHP does that only if you are trying to use $aString as an int.
harisenbon 15y ago
While I would love them to bring the array functions more into line with other OO langauges, the entire language is not structured around that concept, so you would be in essence writing a whole new language. Because almost all the modern PHP frameworks use arrays to pass data, the short-array syntax makes viewing multi-dimensional arrays much easier, and thus will hopefully result in less bugs. Example: $this->link('My Link', array('names'=> array('a', 'b', 'c'), 'values'=> array('a1', 'a2', 'a3') ) ); becomes: $this->link('My Link', ['names'=> ['a', 'b', 'c'], 'values'=> ['a1', 'a2', 'a3'] ]); Just removing the word array makes the code much easier to read, especially when you have deeply nested arrays.
- gdulli 15y ago
  "so you would be in essence writing a whole new language" After having to use PHP for a while, it's no coincidence that these days I am using a whole new language.
antihero 15y ago
Kludgy as it sounds, I just made a list and dict object that was expandable and had more pythonic way of dealing with arrays.

by gdulli 15y ago

ryanb 15y ago

agreed. this is one of my pet peeves with PHP also.

robryan 15y ago

Hard to say that it is simple unless you know the internals.

vmind 15y ago
2 lines in the parser: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_parser.y?r1=313094&r2=313641 http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_langua... The RFC (https://wiki.php.net/rfc/shortsyntaxforarrays https://wiki.php.net/rfc/shortsyntaxforarrays) was actually rejected by the developers, I think it's only really been put in to appease large userland pressure. Find it rather amusing that a 2 change to the parser for an alias would be rejected on 'maintainability' grounds.
- birken 15y ago
  The voting results on the RFC page is from 2008 when it was rejected. The recent vote that decided its inclusion was here: https://wiki.php.net/todo/php54/vote https://wiki.php.net/todo/php54/vote. I think it had pretty solid support from core developers as well as userland people this time around.
zakovyrya 15y ago
And why should everyone know or care about language internals?
- JeremyBanks 15y ago
  If someone is making a statement about how "simple" something is to implement, they should know what they're talking about, no?

Zachhack 15y ago

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

jonathanyc 15y ago
(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).

Tharkun 15y ago

Not to mention the wonderfully inconsistent count() and sort(). Pah.

code_duck 15y ago

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.

wanderr 15y ago
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?
- code_duck 15y ago
  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.
- fooyc 15y ago
  PHP does that only if you are trying to use $aString as an int.

harisenbon 15y ago

While I would love them to bring the array functions more into line with other OO langauges, the entire language is not structured around that concept, so you would be in essence writing a whole new language. Because almost all the modern PHP frameworks use arrays to pass data, the short-array syntax makes viewing multi-dimensional arrays much easier, and thus will hopefully result in less bugs. Example: $this->link('My Link', array('names'=> array('a', 'b', 'c'), 'values'=> array('a1', 'a2', 'a3') ) ); becomes: $this->link('My Link', ['names'=> ['a', 'b', 'c'], 'values'=> ['a1', 'a2', 'a3'] ]); Just removing the word array makes the code much easier to read, especially when you have deeply nested arrays.

gdulli 15y ago
"so you would be in essence writing a whole new language" After having to use PHP for a while, it's no coincidence that these days I am using a whole new language.

antihero 15y ago

Kludgy as it sounds, I just made a list and dict object that was expandable and had more pythonic way of dealing with arrays.