19 ms·

Practically a net neutral time saved in typing at the cost of readability of the object literal. I don't think there will be many cases where I'll be using Map

Practically a net neutral time saved in typing at the cost of readability of the object literal. I don't think there will be many cases where I'll be using Map over an Object literal.

mendort 12y ago
Maybe you can monkey patch Object.prototype to include a toMap function? That way you get nice literals and the benefits of maps.
masklinn 12y ago
Maps have quite a few advantages over bare objects: * they have a length * their keys are typed, not limited to strings. Objects as keys actually works * they can be cleared in a single call * they can easily be iterated over keys, values or (key, value) pairs
- adsense_banned 12y ago
  I've searched but can't find the answer... Do they maintain insertion order?
  - shawnz 12y ago
    Yep. In the ES6 draft: > forEach calls callbackfn once for each key/value pair present in the map object, in key insertion order. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ma...
  - masklinn 12y ago
    They do, which is why you have to give it an iterator.
- berdario 12y ago
  Still, I'd like if Map worked with values m = new Map([[new String(1), 1]]) > Map { "1": 1 } m.get("1") > undefined
  - masklinn 12y ago
    I'm not sure what you'd want here, you specifically allocated a string object and since JS has no notion of object equality it can only use identity.
    - berdario 12y ago
      You can still iterate through all the properties of an object (the indexes associated to the code units, in case of a String) and recursively implement equality on them this way. The fact that, up to ES5, there's been no agreement on which name to use for the equality function and no default implementation for it it's of no excuse to avoid the issue. It's their (the people who standardized it) Map type, and they should've been able to make it as useful as possible.
      - masklinn 12y ago
        > You can still iterate through all the properties of an object and recursively implement equality on them this way. Can't do that for a hashmap since the value can change (by mutating the object) the hash would have to change as well and the object would have to move around. Not a sane proposition.
        berdario 12y ago
        It wouldn't be much different than in any other language, that can let you define a mutable hashable type that breaks the hashability/equality contracts needed by maps. Mutating things that you'd use as keys is a well known no-no, and value equality is the expected behavior among all the developers I know. So implementing this is certainly not any less sane than other tricky behaviours already present in javascript (think equality coercions) and it would give a behavior which makes real code simpler. On top of that, the Map implementation could always call Object.freeze() on the keys that it receives
shawnz 12y ago
This is just a contrived example. In this situation there are a small number of keys that are all known in advance, which is exactly what object literals are for. A map would be more appropriate in situations where you have a large number of keys that are built up at runtime. Similarly, it is the latter situation where the ability to enumerate is important.

Practically a net neutral time saved in typing at the cost of readability of the object literal. I don't think there will be many cases where I'll be using Map over an Object literal.

mendort 12y ago

Maybe you can monkey patch Object.prototype to include a toMap function? That way you get nice literals and the benefits of maps.

masklinn 12y ago

Maps have quite a few advantages over bare objects: * they have a length * their keys are typed, not limited to strings. Objects as keys actually works * they can be cleared in a single call * they can easily be iterated over keys, values or (key, value) pairs

adsense_banned 12y ago
I've searched but can't find the answer... Do they maintain insertion order?
- shawnz 12y ago
  Yep. In the ES6 draft: > forEach calls callbackfn once for each key/value pair present in the map object, in key insertion order. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ma...
- masklinn 12y ago
  They do, which is why you have to give it an iterator.
berdario 12y ago
Still, I'd like if Map worked with values m = new Map([[new String(1), 1]]) > Map { "1": 1 } m.get("1") > undefined
- masklinn 12y ago
  I'm not sure what you'd want here, you specifically allocated a string object and since JS has no notion of object equality it can only use identity.
  - berdario 12y ago
    You can still iterate through all the properties of an object (the indexes associated to the code units, in case of a String) and recursively implement equality on them this way. The fact that, up to ES5, there's been no agreement on which name to use for the equality function and no default implementation for it it's of no excuse to avoid the issue. It's their (the people who standardized it) Map type, and they should've been able to make it as useful as possible.
    - masklinn 12y ago
      > You can still iterate through all the properties of an object and recursively implement equality on them this way. Can't do that for a hashmap since the value can change (by mutating the object) the hash would have to change as well and the object would have to move around. Not a sane proposition.
      - berdario 12y ago
        It wouldn't be much different than in any other language, that can let you define a mutable hashable type that breaks the hashability/equality contracts needed by maps. Mutating things that you'd use as keys is a well known no-no, and value equality is the expected behavior among all the developers I know. So implementing this is certainly not any less sane than other tricky behaviours already present in javascript (think equality coercions) and it would give a behavior which makes real code simpler. On top of that, the Map implementation could always call Object.freeze() on the keys that it receives

shawnz 12y ago

This is just a contrived example. In this situation there are a small number of keys that are all known in advance, which is exactly what object literals are for. A map would be more appropriate in situations where you have a large number of keys that are built up at runtime. Similarly, it is the latter situation where the ability to enumerate is important.