Hacker News Reader

Comment by mnutt | Hacker News Reader

Javascript doesn't really conflate arrays and hashes in the way PHP does. It uses the same bracket syntax for both, but you either instantiate an array or a hash.

I don't think that allowing you to iterate over a hash as if it were an array is all that unforgivable, though it's often not the right thing to do and you can't expect the values in any particular order.

View on HN

> I don't think that allowing you to iterate over a hash as if it were an array is all that unforgivable

it's not even doable in JavaScript: bare objects (~hashes) are iterated with for...in, using that with arrays gives inconsistent results: the array's keys will be iterated as if they were (string) properties, there are no guarantees they'll be iterated in numerical order, and any enumerable property added to the array itself or any of its ancestors will be iterated over as well.

Friends don't let friends iterate over arrays with for...in.

> Friends don't let friends iterate over arrays with for...in.

Which is too bad because it looks so much better.

I just use Array.prototype.[forEach|map|filter] instead, or the equivalent Underscore.js function (which aliases to native when it can) if IE-compatibility is needed.

If you need performances, nothing will beat C-style access anyway. And FWIW, using for...in on an array is slower than using Array.prototype.forEach.

edit: FWIW, even hand-rolling an each() function (in the style of underscore's) will be faster than for...in.

it works this way, though, because an array's keys actually are string properties. It's the array methods that treat them as if they were numeric.

Perl has 3 ways to iterate over a hash: "keys", "values", and "each". The first two do what you'd think; "each" in array context iterates over key/value pairs. All three return their results in an "apparently random" order.

You can also use "for" to iterate over a hash, same as you would over an array, but in that case the hash is converted to a list of alternating keys and values, which isn't as useful.

[edited to correct a typo]

The results are random in order, but consistent between calls, so it's not all bad

I had to look this up because I was thinking otherwise, but now I believe you are correct - it is just inconsistent between runs:

http://perldoc.perl.org/functions/each.html says "Hash entries are returned in an apparently random order. The actual random order is subject to change in future versions of Perl, but it is guaranteed to be in the same order as either the keys or values function would produce on the same (unmodified) hash. Since Perl 5.8.2 the ordering can be different even between different runs of Perl for security reasons (see Algorithmic Complexity Attacks in perlsec)."

> I don't think that allowing you to iterate over a hash as if it were an array is all that unforgivable

Ruby allows this. Both arrays and hashes provide an each method and include the Enumerable module.

Ruby even makes it invisible because of destructuring assignment of block variables.

    ruby-1.9.2-p180 > {1=>2}.each {|k,v| puts "#{k} #{v}"}
    1 2
     => {1=>2} 
    ruby-1.9.2-p180 > {1=>2}.sort.each {|k,v| puts "#{k} #{v}"}
    1 2
     => [[1, 2]]

"You either instantiate an array or a hash" suggests that arrays and hashes are distinct in Javascript, but they aren't. Arrays _are_ hashes (that is, Objects) with some extra functions in their prototype which let them, in the words of the standard, "give special treatment to a certain class of property names."

Yes, you're absolutely right. I meant that in usage you generally either instantiate a plan object and use it as a hash or you instantiate an array and use it as an array, but when you instantiate an array, you can treat it like any other object.

Reply on news.ycombinator.com