Dmitry Soshnikov (2014-10-01T18:50:39.000Z)
forbes at lindesay.co.uk (2016-02-01T12:24:31.052Z)
(Maps are awesome!) **1) Transforming iteration methods** We're currently polyfillying the `Map`, and got some questions from devs. One of them is about transforming iteration methods, like `map` and `filter`. Unfortunately I missed that part of the spec when it was approved, so can someone please remind/clarify -- was it an intended decision not to have `Map#map`, `Map#filter`? I can see only `Map#forEach` in the spec. Are maps "immutable"? -- That's fine, the `map` and `filter` return a new map. **2) Declarative syntax** The other thing to note: currently maps a lack of a nice declarative syntax. This one came from the use-case for maps for dynamic (computed) property names. Previously, we had to allocate an empty object, and then, in the imperative style, append needed props: ```js var requestData = {}; requestData[Names.ID] = id; requestData[Names.EMAIL] = email; requestData.needsReload = true; ... new Request(...) .setData(requestData) .send(); ``` With computed properties of object initialisers it's much simpler and convenient: ```js new Request(...) .setData({ [Names.ID]: id, [Names.EMAIL]: email, needsReload: true, }) .send(); ``` Then thing is: if we'd like to use maps for such use-case, it brings us back to that inconvenient imperative style of assignments (even worse, since you have to repeat that `.set(...)` constantly): ```js var requestData = new Map(); requestData.set(Names.ID, id); requestData.set(Names.EMAIL, email); requestData.set('needsReload', id); ... ``` Yes, we provide the iterable option for the constructor, and it can be rewritten as (and this can even be inlined): ```js var requestData = new Map([ [Names.ID, id], [Names.EMAIL, email], ['needsReload', id] ]); ``` However, obviously, it's too many arrays allocation for such a simple use case. Will it make sense having a nice declarative syntax like: ```js new Map({ [Names.ID]: id, [Names.EMAIL]: email, needsReload: true, }) ``` It can even be done via a simple helper method that transforms this object literal with computed props to the same iterable array of array, but this, unfortunately, doesn't work with all cases like "objects as keys". I don't have the exact idea yet of how such a syntax can look like, but it seems would be nice to have. (unless, the use-case is not for maps, and we should use simple objects here as was shown above)