Adds support for es6 iterators

[ex1st]

@megawac @aearly FYI

[megawac]

is map the only time we'd like to do this switch? Also not sure if tracking indexs even makes sense for a *Map as they won't correspond to the actual index (can't do map[1] to get item.value

[aearly]

I think this is a valid thing to do. I think it's odd to iterate over a map and get [key, val] as the value with an arbitrary numeric index.

[ex1st]

@megawac if wan't use map's indexes it makes iterator easy - just replace to lodash.prototype.next()
What do you think?

[megawac]

We are not going to import lodash chaining

[ex1st]

@megawac corrected.

[aearly]

This is really cool. 👍

[aearly]

Damn, I was looking for some precedent in how to handle Maps, but niether Lodash nor Ramda have real support for ES6's new collection types yet.

It does seem weird to have a special case just for Map iterators, but on the other hand, it is a built-in data type for JS now. I also think using the Map's keys as separate arguments to iteratees will better match user expectations. It is a special case, but I think we will have just this single special case. I see it as analogous to iterating over an Object vs. an Array.

[megawac]

I also think using the Map's keys as separate arguments to iteratees will better match user expectations.

I disagree, if they want keys they should pass map.entries() iterator instead of the map itself

[megawac]

I really don't like tracking this index. People should pass .entries if they want access to the key. i may not correspond to the real index. Just leave key undefined

[aearly]

Some sort of index is needed for map(Series|Limit) to work.

[megawac]

Good point fine with this then