Dmitry Soshnikov (2014-10-01T18:50:39.000Z)
Hi,

(Maps are awesome!)

1. Transforming iteration methods

We're currently polyfillying the `Map`, and got some questions form 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 hap
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:

```
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:

```
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):

```
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):

```
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:

```
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)

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/1e2900b8/attachment-0001.html>
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)