Why does Array.from also take a mapFn?
allen at wirfs-brock.com
Mon Jun 24 09:48:52 PDT 2013
On Jun 24, 2013, at 9:42 AM, Domenic Denicola wrote:
> From: Allen Wirfs-Brock [allen at wirfs-brock.com]
>> My recollection is that we first discussed that the existence of Array.from make this issue somewhat less important because, just as you point out, .from can be used in conjunction with anything that produces an Iterable such as V.from(v.map(val => val * 2))
>> That led to further discision of that usage and we got into things like the last example:
>> // Turn an array of nodeNames into NodeList of nodes
>> NodeList.from( ["div"], node => document.createElement(node) );
> I think I must be missing something. Why is this superior to
> NodeList.from(["div"].map(node => document.createElement(node));
> which you gave as an example just a few lines above? In other words, why does `Array.from` accept a second parameter at all?
> Another question that I don't think got an answer, or if it did I was unable to understand it. Why is "map" singled out for `Array.from` instead of, say, "filter"? It seems arbitrary.
On Feb 14, 2013, at 8:47 AM, Nathan Wall wrote:
> Hey Allen, thanks for clarifying.
> What will happen to other Array methods which currently return Arrays? `filter` is the primary one that comes to mind. Will `uint32array.filter((v) => v != 0)` return a Uint32Array? (I think it should behave the same way `map` does.)
filter, splice, splice, reverse, etc. all copy elements that from an existing array or array subclass so the result can/should be the same class is the source array. Map is different because it can produce new element values of an arbitrary kind that may not fit into the same kind of array as the source array
We should probably all go back and review that thread.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss