Thanks for the clarification. I thought the mapping was applied afterwards.
I would still argue that it would be better to skip it all together than having it and not working like the existing map function. So Array.from(array-like).map(mapFn) is the way to go then? ons 3 maj 2017 kl. 13:06 skrev T.J. Crowder <[email protected] >: > `Array.prototype.map` doesn't pass a reference to the *newly-created* > array either. The third argument `Array.prototype.map` passes the mapping > function is a reference to the *existing* array, not the new one. With > `Array.from`, there is no existing array to pass. > > Not having the mapping functions (either of them) get a reference to the > array being constructed avoids an entire class of errors caused by the > mapping function modifying the array as it's being constructed. > > -- T.J. Crowder > > On Wed, May 3, 2017 at 11:50 AM, the kojoman <[email protected]> wrote: > >> Array.map(mapFn) calls the mapFn(v,i,a) passing the currentValue, >> currentIndex and the array it is iterating over as arguments. >> I was happy to find out about Array.from(itterable, mapFn, thisArg), but >> unfortunately, the mapping didn't work as expected. >> It seems, Array.from doesn't pass in the newly created array to the >> mapFn. Why is that? >> >> For instance I was expecting Array.from("aabc", (v,i,a) => { if(a[i] === >> a[i-1]) a.splice(i,1) }) to evaluate to ["a","b","c"], but a is undefined. >> Is there a reason why the mapFn isn't called the same way as an Array.map >> function is? >> -John >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
