I find PHP's arrays amusing. It's as if Rasmus couldn't decide whether they should be associative or indexed, so he made them both.

Although I suppose, strictly speaking, JavaScript has the same thing. (not intentionally, but you can make an array that is both if you really want to)

It's not a bad thing itself to make "arrays" work like that, except, you can't call them arrays then.

For example, Lua uses a similar approach ("tables") and works just fine. AFAIK, it does certain optimizations under the hood to make sure numerically indexed tables behave efficiently (like arrays). Maybe PHP does the same thing, but its terminology is confusing.

P.S.: I dream of a future where Lua is the primary tool for web development. It's perfect for that purpose as a language, but unfortunately, lacks the necessary ecosystem :(

What's wrong with array_keys? It's extremely useful.

Java has keySet(), Ruby has hash.keys, etc.

Your second argument is even dumber. Yes, PHP lets you do lots of things, which improve the speed of development. If you don't like it, don't write it that way.

> What's wrong with array_keys? It's extremely useful.

I don't think he was arguing about the utility. I think he meant that: array_keys($aHash); is less desirable than: aHash.keys. Also, if you you really look at the PHP example, the semantics really suck.

I wouldn't pick on the example, but you've made me curious: how does it improve the speed of development to have array("a" => "green", "red", "blue") ?

This is just a side-effect of the fact that arrays in PHP are also hash-maps. That improves the speed of development, not your example.

And you think it's a good idea to have arrays be also hash maps?

As long as you're aware of it.

see, you don't get it. Arrays don't have keys. Reading this function name makes no sense.