4 ms·

To play devils advocate here... There's nobody saying a map has to be a hash map. It could be any sort of map. Look at JavaScript. Those are just plain maps. W

To play devils advocate here... There's nobody saying a map has to be a hash map. It could be any sort of map. Look at JavaScript. Those are just plain maps. Why should expecting sophisticated hashes for simple maps be the default?

kevingadd 13y ago
JS Object is actually an ordered map, because they failed to specify whether it was ordered or not early on, and we ended up stuck with the particular map implementation IE used (there are now lots of applications out there that depend on getting back k/v pairs in the order they were added).
- bshimmin 13y ago
  In the ECMAScript language spec, at least as far back as 1999, it quite specifically does say "unordered".
  - magicalist 13y ago
    yes, but kevingadd was (almost certainly) talking about in practice. In fact, I vaguely recall reading that the V8 team originally wanted to abandon insertion-order enumeration for performance but couldn't because too much code broke on the web. It's not quite insertion order, though, which is one of the issues with just specifying it in ES6 as it's implemented. If you insert with a numeric key (or a string that's strictly a number), I believe the JS engines don't agree on the order in which the numeric key will be enumerated in relation to the alphanumeric ones (v8 and spidermonkey will put the numeric ones ahead of all the keys, sorted ascending, then do the rest in insertion order, for instance).
zwegner 13y ago
Another good example is C++, std::map is (usually) a red-black tree.
blahedo 13y ago
I'm not saying it has to be a hash map either; just that the author's post is consistent with plain old hashtable behaviour (i.e. the results are not iterated in insertion order, nor in natural order). By posting just a single example of a map iteration, the author has not demonstrated that the iteration order is "random" nor even that it changes each time through (though from other posts here, I gather that it does). Essentially, I'm not calling out the author's claim as unbelievable, I'm calling out the article for being unconvincing.

kevingadd 13y ago

JS Object is actually an ordered map, because they failed to specify whether it was ordered or not early on, and we ended up stuck with the particular map implementation IE used (there are now lots of applications out there that depend on getting back k/v pairs in the order they were added).

bshimmin 13y ago
In the ECMAScript language spec, at least as far back as 1999, it quite specifically does say "unordered".
- magicalist 13y ago
  yes, but kevingadd was (almost certainly) talking about in practice. In fact, I vaguely recall reading that the V8 team originally wanted to abandon insertion-order enumeration for performance but couldn't because too much code broke on the web. It's not quite insertion order, though, which is one of the issues with just specifying it in ES6 as it's implemented. If you insert with a numeric key (or a string that's strictly a number), I believe the JS engines don't agree on the order in which the numeric key will be enumerated in relation to the alphanumeric ones (v8 and spidermonkey will put the numeric ones ahead of all the keys, sorted ascending, then do the rest in insertion order, for instance).

zwegner 13y ago

Another good example is C++, std::map is (usually) a red-black tree.

blahedo 13y ago

I'm not saying it has to be a hash map either; just that the author's post is consistent with plain old hashtable behaviour (i.e. the results are not iterated in insertion order, nor in natural order). By posting just a single example of a map iteration, the author has not demonstrated that the iteration order is "random" nor even that it changes each time through (though from other posts here, I gather that it does). Essentially, I'm not calling out the author's claim as unbelievable, I'm calling out the article for being unconvincing.