Why does Array.from also take a mapFn?

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jun 25 12:02:29 PDT 2013


On Jun 25, 2013, at 7:46 AM, Jason Orendorff wrote:

> On Mon, Jun 24, 2013 at 12:01 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
>>> 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.
>> 
>> It's not at all arbitrary: filter isn't an operation used to change the
>> value of the items in the returned iterable.
> 
> Oh, I didn't get that Array.prototype.filter and the rest are going to
> be subclass-friendly! Hmm. I want to love this change, but I'm
> ambivalent. Typed arrays are fixed-length, and DOM NodeLists aren't
> even constructible. :-\

see http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_jan_29_2013&cache=cache&media=meetings:subclassing_builtins.pdf 
http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_jan_29_2013&cache=cache&media=meetings:typedarray_status.pdf 
And the minutes from Jan 2013 TC39 meeting.

Note that TC39 agreed that  Typed Arrays will have all of the appropriate Array.prototype methods but we really didn't reach a final conclusion whether that is via actual inheritance from Array.prototype or via (possible) distinct implementations on a TypedArray prototype.  I'm working right now on resolving that.

One of the issues is that all the existing Array.prototype method specs  Uint32 convert the "array" lengths before processing them.  However, TC39 agreed that we want to allow TypedArrays with lengths greater than 2^32-2 .  If Typed Arrays are going to inherit methods from Array.prototype we would have to eliminate applying Uint32 to the length. There is uncertainty about whether that would break anything that actually exists. 

> 
> NodeList is currently experimentally specified to be `[ArrayClass]`,
> which would cause NodeList.prototype to inherit from
> Array.prototype.[1][2] NodeLists would have .filter(). This is
> awkward: with the ES5 algorithm, `nodelist.filter(pred)` will work,
> returning a plain Array; but the proposed subclass-friendly algorithm
> will try to create a NodeList---and throw an exception.
> 
>  [1]: http://dom.spec.whatwg.org/#interface-nodelist
>  [2]: http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass
> 
> If (as I am beginning to suspect) it just makes no sense for NodeList
> to be a subclass of Array, we should urgently figure out some kind of
> recommendation for such cases. DOM has more than just the one.

What we probably need to do is make the algorithm (in my previous message) that chooses the result collection kind a @@method.  Then things like NodeList can choose how they want to work.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130625/689d42f7/attachment.html>


More information about the es-discuss mailing list