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 <[email protected]> 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 <[email protected]>: >> 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 >>> <[email protected]> wrote: >>>> On Wed, May 3, 2017 at 7:35 PM, Jordan Harband <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
