On Tue, Oct 7, 2014 at 2:20 PM, Tab Atkins Jr. <[email protected]> wrote:
> On Tue, Oct 7, 2014 at 2:11 PM, Dmitry Soshnikov > <[email protected]> wrote: > > On Tue, Oct 7, 2014 at 1:45 PM, Bergi <[email protected]> wrote: > >> > >> I think all of the above examples are trying to create a case such as > >> > >> | UInt32Array.from(nodelist, node => parseInt(node.value, 10) ); > >> > >> where neither can nodes be stored in an Uint32Array nor integers be > stored > >> in a NodeList. > > > > > > Not sure what you mean by "nor integers be stored in a NodeList", but how > > does your example differ from: > > He meant that, assuming NodeList had a .map() that returned another > NodeList (in general, assuming that .map() is type-preserving, which > it's not currently), you wouldn't be able to easily do a "map it > first, then translate into the new collection" - you'd have to > explicitly translate it into a collection that can hold both UInt32 > and Node values, then map, then translate. > > > ``` > > UInt32Array.from(nodeList.map(node => parseInt(node.value, 10))); > > ``` > > This works because .map() is not type-preserving, and automatically > produces an Array (which can accept anything). > > I see. Actually it doesn't work, your're correct, since `Array.prototype.map` does preserve the kind (at least in the latest draft). And the `UInt32Array.from(...)` would be consuming a nodeList, not an array. Will the `nodeList.map(node => parseInt(node.value, 10));` by itself actually work then? Dmitry
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
