Why does Array.from also take a mapFn?
rbuckton at chronicles.org
Sun Jun 30 15:41:27 PDT 2013
Couldn't you just do:
var squaredSmalls = Int16Array.from((v*v for v of smalls));
Or is the allocation of a generator expensive enough to warrant the mapFn argument? Alternatively, is it the need to support a map on a non-iterable "array-like"?
Sent from my Windows Phone
From: Tab Atkins Jr.<mailto:jackalmage at gmail.com>
Sent: 6/24/2013 1:28 PM
To: Domenic Denicola<mailto:domenic at domenicdenicola.com>
Cc: es-discuss<mailto:es-discuss at mozilla.org>
Subject: Re: Why does Array.from also take a mapFn?
On Mon, Jun 24, 2013 at 12:55 PM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> Thanks Allen. The
>> var squaredSmalls_try2= Int16Array.from(smalls.map(v=> v*v)); // still no good, because intermediate array is Int8Array
> example certainly clears it up for me. Tricky stuff.
> I was going to write "it's still a bit weird to me that we overload `Array.from` with the mapping functionality", but then I realized this is only weird because of my preconceptions about `Array.from` dating back from when we first discussed it on-list.
> Taken on its own, without any historical bias, I think it's fine for `Array.from`, and more importantly `Int16Array.from` etc., to take a mapping function. You derive a new `Int16Array` "from" another iterable, optionally via some rule. Makes sense!
Yup; in other words, Array.from is just the type-converting Array#map
(defaulting its callback to the identity function).
es-discuss mailing list
es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss