Why does Array.from also take a mapFn?

Jason Orendorff jason.orendorff at gmail.com
Mon Jun 24 08:42:30 PDT 2013


According to the January 30 meeting notes, Array.from is getting
optional map functionality.[1]

This is motivated by the following example:

    class V extends Array {
        constructor(...args) {
            super(...args);
        }
    }

    var v, m;
    v = new V(1, 2, 3);
    m = v.map(val => val * 2);
    console.log( m instanceof V ); // false :(

Of course changing Array.from doesn't fix this; v.map() still returns
an Array, same as before. And there was already an easy workaround:
    m = V.from(v.map(val => val * 2));

This workaround seems superior to the proposal, because it's more
generally applicable. The same thing works for the results of
.filter(), .concat(), etc. Something very similar works for Set:

    m = Set(v.map(...));

Clearly not every possible composition of two primitives needs to be a
builtin function. Why this particular one?

Cheers,
-j

  [1]: https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md#revising-the-array-subclassing-kind-issue


More information about the es-discuss mailing list