Why doesn't Array.from() pass the array to the mapFn?
ben.katz at gmail.com
Thu May 4 04:32:48 UTC 2017
I have a couple ideas why:
1. It discourages separation of concerns - cloning/filtering/mapping...
2. Iterables can change mid iteration. Better to make the clone process as atomic as possible.
> On 4 May 2017, at 1:12, the kojoman <kojoman at gmail.com> wrote:
> Thanks Jordan, filter was, of course, what I was looking for. Just got carried away, when I saw it had a mapFn as an option and thought I could use that somehow to cut a corner.
> By the way, and kind of off topic, why is mutating a list mid-iteration bad news? I'm just curious, and obviously not a computer engineer.
> ons 3 maj 2017 kl 23:37 skrev Jordan Harband <ljharb at gmail.com>:
>> Good point :-) i guess as the destination index it makes sense, altho i've always thought of it as the source index.
>>> On Wed, May 3, 2017 at 12:58 PM, T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:
>>>> On Wed, May 3, 2017 at 7:35 PM, Jordan Harband <ljharb at gmail.com> wrote:
>>>> (an index in Array.from wouldn't make sense, because Array.from takes an iterable *or* an arraylike - and only an arraylike would be guaranteed to have an index, or even a "list" at all)
>>> And yet, [it provides one](https://tc39.github.io/ecma262/#sec-array.from). It's the index that will be used to set the array entry from the result. It's only the third argument (the source object) that `Array.from` doesn't include.
>>> -- T.J. Crowder
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss