On Wed, Oct 1, 2014 at 11:57 AM, Rick Waldron <waldron.rick at gmail.com>
wrote:

>
>
> On Wed, Oct 1, 2014 at 2:50 PM, Dmitry Soshnikov <
> dmitry.soshnikov at gmail.com> wrote:
>
>> 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.
>>
>
>
> Only with regard to time. I expect there will be substantial additions to
> Map and Set in ES7 (as long as the work is done, of course).
>

Hm, sounds like two copy-pasting algorithms from the same `Array#map`,
`Array#filter`, or just tweaking the `Map#forEach` (I might be missing
something).



>
>
>>
>> 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,
>> })
>> ```
>>
>
> This doesn't work because Maps allow objects as keys.
>
>
Yes, I said it myself above. That's the thing -- I'd like to thing about
some special syntax maybe. Don't know yet, probably map as a construct for
declarative cases like:

```
// Declarative
Map {
  [foo]: 1,
  bar: 2,
}

// Imperative (via constructor)
new Map([ // brrr..
  [foo, 1],
  ['bar', 2]
])
```

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/c3561398/attachment.html>

> I expect there will be substantial additions to
> Map and Set in ES7 (as long as the work is done, of course).

Hm, sounds like two copy-pasting algorithms from the same `Array#map`,
`Array#filter`, or just tweaking the `Map#forEach` (I might be missing
something).

> This doesn't work because Maps allow objects as keys.

Yes, I said it myself above. That's the thing -- I'd like to thing about
some special syntax maybe. Don't know yet, probably map as a construct for
declarative cases like:

```js
// Declarative
Map {
  [foo]: 1,
  bar: 2,
}

// Imperative (via constructor)
new Map([ // brrr..
  [foo, 1],
  ['bar', 2]
])
```