Hacker News Reader

Hacker News

Comment by gdulli | Hacker News Reader

Full thread

gdulli

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.

View on HN

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

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.

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.

PHP does that only if you are trying to use $aString as an int.

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.

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

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

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

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

And why should everyone know or care about language internals?

If someone is making a statement about how "simple" something is to implement, they should know what they're talking about, no?

2 lines in the parser: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_langua...

The RFC (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.

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. I think it had pretty solid support from core developers as well as userland people this time around.

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

Reply on news.ycombinator.com