On Thu 20 Nov 2014 01:49, Dmitry Soshnikov dmitry.soshni...@gmail.com writes:
At the meeting it was decided not to go with `map` and `filter` sitting
on `Map.prototype`, but instead to use iterators in the way like:
```
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
From: Andy Wingo [mailto:wi...@igalia.com]
Is there a nice way to do this for the default iterator?
https://esdiscuss.org/topic/map-filter-map-and-more#content-57
Also, I thought that map, filter, and such were to be on the
Iterator.prototype. That precludes multi-arg map functions
On Wed, Nov 19, 2014 at 4:49 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
(For the history of this thread to refer to it later)
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
.filter((v, k, m) = { ... })
.collect(); // returns a new map after all
Where can I read about the rationale to not put those methods on the Map
prototype? I'm curious why that was okay for the Array class, but not okay
for Map and Set.
On Thu, Nov 20, 2014 at 12:32 PM, Axel Rauschmayer a...@rauschma.de wrote:
At the meeting it was decided not to go with `map` and
On Thu, Nov 20, 2014 at 10:32 AM, Axel Rauschmayer a...@rauschma.de wrote:
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sounds good! (I always end up calling one of the iterators on python dicts
anyway, since I can never remember what the default iterator behavior is.)
Yeah. There is a separate idea that we should probably define
Map.prototype.{map, filter,
On 20 Nov 2014, at 1:49 , Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
(For the history of this thread to refer to it later)
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
From: Axel Rauschmayer [mailto:a...@rauschma.de]
Question – shouldn’t this example be written as follows?
Yes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, Nov 20, 2014 at 10:42 AM, Domenic Denicola d...@domenic.me wrote:
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
I presume that .collect() expects an iterator of [k,v] pairs or something?
Also: this is the first I've heard of .collect(). I presume that'll show up
in the spec?
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Interesting idea, but I'm not sure how it's supposed to work in practice.
Doesn't answer all of your questions, and is probably half-assed in various
ways, but here is some stuff that we came up with in some live-coding during
the meeting:
(For the history of this thread to refer to it later)
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
.filter((v, k, m) = { ... })
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:
```
Dmitry Soshnikov wrote:
Is this something what is ready for discussion on a meeting (in
particular, tomorrow's meeting)?
You put something on the agenda, cool.
https://github.com/tc39/agendas/blob/master/2014/11.md
/be
___
es-discuss mailing list
On Mon, Oct 6, 2014 at 9:37 AM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
This meansMap.prototype.mapetc. -- or %ItereablePrototype%.map if not
Array.prototype.map etc. -- are the eager collection-generic companions.
Bear with me, trying to develop a half-thought. To say
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,
On Wed, Oct 8, 2014 at 3:09 PM, Brendan Eich bren...@mozilla.org 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
[1]:http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
Problem is :: vs. just dot, and now you have two problems. I'm actually
good with FP inside-out, could learn to love :: if we add it, but the main
objection IMHO is two-problems. OOP means just dot.
That reminds me:
Coming form other languages, double colons is used as a static thing,
although we don't need (?) this convention in ES6 classes, and I agree it
looks ugly anyway.
I wonder if here `:` would work instead, because I'd personally find any
other usage of the thin arrow `-` confusing *
Regards
* I
On Sat, Oct 4, 2014 at 10:03 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
This case I'd probably make as `Map#mapWithKey`, however there other
questions arise like, should the returned pair replace the existing, or
create a new one, if the key is different?
```
({a =
* I personally see `-` as a shortcut for `function`
I'm a C sympathizer, so I don't see it the quite the same, but I
understand. Regardless of the token, I feel like a generalized ref_get/set
mechanism would be great.
___
es-discuss mailing list
On Tue, Oct 7, 2014 at 8:51 AM, Kevin Smith zenpars...@gmail.com wrote:
[1]:http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
Problem is :: vs. just dot, and now you have two problems. I'm actually
good with FP inside-out, could learn to love :: if we add it, but the main
My question is: If we have -, how much need would there still be for
:: or @? If - can subsume the practical need for either or both of
the others, that would be interesting.
That was the idea, but it's been a while since I went through that
exercise. I need to review.
On Sat, Oct 4, 2014 at 10:03 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Sat, Oct 4, 2014 at 5:58 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Domenic Denicola
Unless I'm missing something
Brendan Eich wrote:
This meansMap.prototype.mapetc. -- or %ItereablePrototype%.map if not
Array.prototype.map etc. -- are the eager collection-generic companions.
Bear with me, trying to develop a half-thought. To say it with code:
```js
Object.defineProperty(%IteratorPrototype%, 'map', {
Caffeinating still, obvious bugfix below:
Brendan Eich wrote:
```js
Object.defineProperty(%CollectionPrototype%, 'map', {
value: function (fun) {
let result = new this.constructor();
for (let [key, val] of this) {
result.set(key, val);
```js
Note the this.clone() call. This is novel, and required to avoid exhausting
the receiver iterator.
This is noteworthy and worth keeping in mind regardless of the rest of the
discussion. I think I would be fine having %IterablePrototype%.map exhaust the
iterator. I would `.clone()` manually
Domenic Denicola wrote:
Note the this.clone() call. This is novel, and required to avoid exhausting
the receiver iterator.
This is noteworthy and worth keeping in mind regardless of the rest of the
discussion. I think I would be fine having %IterablePrototype%.map exhaust the
iterator. I
From: Brendan Eich [mailto:bren...@mozilla.org]
For iteration, sure. For map or other functional (pure?!) APIs? Yikes.
If in ES7 we build up the duality between iterables and observables, add
for-on, pave the way toward FRP, then `map` as a protocol (part) should be
pure with respect to
On Mon, Oct 6, 2014 at 1:34 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
This is iterables vs. iterators IMO. Iterators are inherently stateful and
I'd expect anything that uses them to consume them, even something named
map. Iterables of course would not be.
I agree. It's
Good to known (and I had heard this via Python community channels
already). Still feels wrong, given name polymorphism on `map`. Perhaps
we just plow ahead.
Still seems like someone (at some layer) will want iter.clone(). Vouch?
/be
Jason Orendorff wrote:
OnMon, Oct 6, 2014 at 1:34 PM,
On Sat, Oct 4, 2014 at 10:03 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Sat, Oct 4, 2014 at 5:58 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Domenic Denicola
Unless I'm missing something
From: Brendan Eich [mailto:bren...@mozilla.org]
But entries returns an iterator, and if we define %IteratorPrototype% to
create a new instance of the right class given its |this| parameter, in this
case Map and not MapIterator, then no need for the new Map() wrapper.
This seems like it'd
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@mozilla.org]
But entries returns an iterator, and if we define %IteratorPrototype% to
create a new instance of the right class given its|this| parameter, in this case
Map and not MapIterator, then no need for the new Map()
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Dmitry
Soshnikov
Thanks, done. https://github.com/tc39/ecma262/pull/13
This seems less useful than adding %IteratorPrototype%.map and
%IteratorPrototype.filter. It also clarifies some of the confusion about
whether you are
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic
Denicola
Unless I'm missing something (quite possible!), I would prefer not to add new
methods to Map and Set when they could be added to %IteratorPrototype%.
Yeah, I'm missing something. It's the difference in
On Sat, Oct 4, 2014 at 5:58 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Domenic Denicola
Unless I'm missing something (quite possible!), I would prefer not to
add new methods to Map and Set when they could be
Dmitry Soshnikov wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic
Denicola
- show quoted text -
Unless I'm missing something (quite possible!), I would prefer not to add
new methods to Map and Set when they could be added to %IteratorPrototype%.
Yeah,
On Wed, Oct 1, 2014 at 6:33 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 1:26 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy
On Thu, Oct 2, 2014 at 12:00 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 6:33 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Wed, Oct 1, 2014 at 1:26 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Wed, Oct 1, 2014 at 12:59 PM, Rick
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
On Wed, Oct 1, 2014 at 11:57 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 2:50 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Hi,
(Maps are awesome!)
1. Transforming iteration methods
We're currently polyfillying the `Map`, and got some questions form
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);
Not sure if this is sufficient motivation to accelerate the timeline for
adding suitable parallels from Array.prototype, but it may be worth
recalling what developers did last time there were obvious gaps in what a
native prototype provided. Array#contains, anyone?
On Wed, Oct 1, 2014 at 3:28
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate the timeline
It's not about motivation, it's about realistic time constraints. TC39
has already had to push out 6 months and that was not taken well by both
the
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate the timeline
It's not about motivation, it's about realistic time constraints. TC39
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate the timeline for
adding suitable parallels from Array.prototype, but it may be worth
recalling what developers did last time there were obvious gaps in what a
native
On Wed, Oct 1, 2014 at 4:17 PM, Axel Rauschmayer a...@rauschma.de wrote:
On Oct 1, 2014, at 22:12 , Axel Rauschmayer a...@rauschma.de wrote:
1. Transforming iteration methods
We're currently polyfillying the `Map`, and got some questions form devs.
One of them is about transforming
Ah, thanks! Then I’d wrap the result of `entries()` in `Array.from()`. In ES7,
we’ll hopefully be able to use comprehensions or iterator helper functions.
On Oct 1, 2014, at 22:27 , Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Oct 1, 2014 at 4:17 PM, Axel Rauschmayer
```js
let map2 = new Map(map1.entries().filter((key, value) = key = 0));
let map2 = new Map(map1.entries().map((key, value) = [key * 2, value *
2]));
entries() returns an iterator, not an array.
let map2 = new Map([...map1].map(([k, v]) = [k, v * 2])
Kevin Smith wrote:
entries() returns an iterator, not an array.
let map2 = new Map([...map1].map(([k, v]) = [k, v * 2])
Sweet!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Oct 1, 2014 at 4:38 PM, Axel Rauschmayer a...@rauschma.de wrote:
Ah, thanks! Then I’d wrap the result of `entries()` in `Array.from()`. In
ES7, we’ll hopefully be able to use comprehensions or iterator helper
functions.
Don't need to do that either.
let map1 = new Map([[-1, -1], [0,
On Wed, Oct 1, 2014 at 4:41 PM, Kevin Smith zenpars...@gmail.com wrote:
```js
let map2 = new Map(map1.entries().filter((key, value) = key = 0));
let map2 = new Map(map1.entries().map((key, value) = [key * 2, value *
2]));
entries() returns an iterator, not an array.
let map2 = new
On Wed, Oct 1, 2014 at 1:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin jmar...@gmail.com wrote:
Not sure if this is sufficient motivation to accelerate
On Wed, Oct 1, 2014 at 12:28 PM, Axel Rauschmayer a...@rauschma.de wrote:
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
On Wed, Oct 1, 2014 at 1:38 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Oct 1, 2014 at 4:26 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Wed, Oct 1, 2014 at 12:59 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 3:51 PM, Jeremy Martin
Dmitry Soshnikov wrote:
Not ideal either. Usually langs provide nice declarative syntax for
such things. E.g. we have[1] the same in the HACK language, and use it
well everyday when need a map.
But this part is of course not for ES6, hope ES7-ish.
[1]
On Wed, Oct 1, 2014 at 4:51 PM, Brendan Eich bren...@mozilla.org wrote:
Dmitry Soshnikov wrote:
Not ideal either. Usually langs provide nice declarative syntax for such
things. E.g. we have[1] the same in the HACK language, and use it well
everyday when need a map.
But this part is of
We could definitely have Map and Set literals:
const map = {1 = one, two = true, false = three};
Would that be tricky to parse if keys can be arbitrary expressions (incl. array
literals)?
const set = {1, two, false};
If you still buy Harmony of My Dreams, prefix # before { to get
Axel Rauschmayer wrote:
We could definitely have Map and Set literals:
const map = {1 = one, two = true, false = three};
Would that be tricky to parse if keys can be arbitrary expressions
(incl. array literals)?
The issue would be arrow function expression keys:
const map = {x = x*x =
60 matches
Mail list logo
