5 ms·

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 ha

by mnutt 15y ago

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.

jleader 15y ago
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]
- akronim 15y ago
  The results are random in order, but consistent between calls, so it's not all bad
  - ratsbane 15y ago
    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 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)."
epochwolf 15y ago
> 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.
- deleted 15y ago
  [deleted]
- JulianMorrison 15y ago
  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]]
masklinn 15y ago
> 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.
- __david__ 15y ago
  > Friends don't let friends iterate over arrays with for...in. Which is too bad because it looks so much better.
  - masklinn 15y ago
    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.
- voyou 15y ago
  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.
voyou 15y ago
"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."
- mnutt 15y ago
  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.

by mnutt 15y ago

jleader 15y ago

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]

akronim 15y ago
The results are random in order, but consistent between calls, so it's not all bad
- ratsbane 15y ago
  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 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)."

epochwolf 15y ago

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

deleted 15y ago
[deleted]
JulianMorrison 15y ago
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]]

masklinn 15y ago

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

__david__ 15y ago
> Friends don't let friends iterate over arrays with for...in. Which is too bad because it looks so much better.
- masklinn 15y ago
  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.
voyou 15y ago
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.

voyou 15y ago

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

mnutt 15y ago
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.