Map: filter/map and more

Dmitry Soshnikov dmitry.soshnikov at
Mon Nov 17 11:24:45 PST 2014

Is this something what is ready for discussion on a meeting (in particular,
tomorrow's meeting)?

Regardless, whether the `map` and `set` will be directly on the
`Map.prototype` or on some generic `%CollectionPrototype%`, the user-level
API will stay the same, right? And will be used as:

```, k) => { ... });

I was just curious, is it already the time when it can be confirmed on a
meeting, that the API will likely be this (assuming we have `map.forEach`
already)? We'd like already to extend the `Map` and `Set` API (by extending
the ES6 base implementation) with several new methods, and start using them.

If this spec
is good enough to discuss it and can be confirmed, will it be a good time
on the following meeting? This PR for agenda wasn't merged for almost a

If it can be confirmed already now, and no actual meeting discussion is
needed for this, I'm fine with this as well.

The only thing that may not confirm it, is using that new binding method
`::` operator and iter tools:

import {map} form 'iter-tools'


But this as I understand is not even in early stage of a proposal (and
again, having dependency/correlation on `map.forEach` probably the `map`
and `filter` will nevertheless be used as just ``).

P.S.: besides these two methods, maps and sets API is pretty basic at the
moment and doesn't have many "every-day to use" which are available in
other languages in these collections: like the most obvious "intersect" or
"union" operations for sets, etc. However, we can start with "map" and
"filter" yet ;)


On Wed, Oct 8, 2014 at 8:05 PM, Dmitry Soshnikov <dmitry.soshnikov at
> wrote:

> On Wed, Oct 8, 2014 at 3:09 PM, Brendan Eich <brendan at> wrote:
>> Dmitry Soshnikov wrote:
>>>     The Collection protocol thus consists of at least .constructor,
>>>     @@iterator, .set. (Is there a better way to clone? Don't want a
>>>     new protocol where an old one will suffice!) This Collection
>>>     protocol would include Map and maplikes but leaves out Set, Array,
>>>     Object -- appropriately.
>>> As long as it can be generic enough for `Map`, `Set`
>> Set methods include add, whereas Map has set. Set lacks a get method,
>> whereas Map of course has one. So not the same protocol.
> I see, yeah, it's doable, and potentially they can be handled via abstract
> operations with checking kind of a collection (`IsSet`, `IsMap`), and
> setting needed entries (`AddEntry` would cover `set` for maps, and `add`
> for Sets), and `GetEntry` would return needed thing since sets are just
> backed by maps. However, this seems not a big win in terms of constant
> runtime checks for this, and probably having a separate algorithms are
> better (even if some parts are repeated).
> If you want to have just an explicit protocol/interface for "MapLike"s and
> "SetLikes" (i.e. with any explicit `set` method, and stuff which can be
> implemented at user-level by any object), it's possible. Although, this
> interface implementation can also be just replaced with sub-classing of the
> `Map`, and the same algorithm works. It's just a difference b/w duck-typing
> (the protocol, that any object may implement regardless its hierarchy), or
> the inheritance. Will think about it, and maybe will come up with a spec.
> Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list