Allen Wirfs-Brock (2014-03-04T17:23:28.000Z)
On Mar 4, 2014, at 8:17 AM, C. Scott Ananian wrote:

> While we're on the topic, let me bang the drum one last time for tweaking some of the `Array` built-ins so that they can be applied to `TypedArray`s. The fact that there are separate `Array.from` and `%TypedArray%.from` methods in the spec (for example) makes me sad. IIRC all that is needed in `Array.from` is to avoid writing the length field if the length of the receiver is already correct. Similarly, if we defined a `GetLength` helper that special-cased instances of `TypedArray`, the definitions of `Array#forEach`, etc could simply say, "`%TypedArray%#forEach` is strictly equal to `Array#forEach`".
> 
> Of course implementors will specialize on the receiver type, but this detail shouldn't be exposed in the spec IMO.
>   --scott
> 
There's actually a big difference between %TypedArray%.from and Array.from.  The typed array version must accurately determine the number of elements in the new array be instantiating it.  The regular array can pre-instantiate the new array and dynamically adjust its length. This affects a number of details of the algorithms. There are other cases where there are variations to the array method algorithms necessary to deal with the potential spareness of regular arrays.

This is the case for several of the array methods but for many of them, the same algorithmic description can be used for both Arrays and Typed Arrays.  In those cases, the ES6 spec. doesn't duplicate the algorithm but instead the Typed Array method specification simply reference the corresponding Array method specification. For example: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%.prototype.foreach 

There was one issue I had to make a decision on.  In the cases where the same algorithm was applicable to both Array and typed Array should a single (same identify) function be used in both Array.prototype and %TypedArray%.prototype or should a distinct function be used for each.  I choose the latter because it seems to allow for more implementation flexibility.  There are lots of ways that some of these algorithms might be optimized if you know you are dealing with a typed array. I wanted to give implementations that option and the most straightforward way to do so is to simply say that, for example, Array.prototype.foreach and %TypedArray%.prototype.forEach are distinct function objects.  That way they can have distinct implementations.  However, if an engine whats to share the same implementation level code between the two functions it could still do that.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140304/152561e0/attachment-0001.html>
domenic at domenicdenicola.com (2014-03-07T21:43:34.564Z)
There's actually a big difference between %TypedArray%.from and Array.from.  The typed array version must accurately determine the number of elements in the new array be instantiating it.  The regular array can pre-instantiate the new array and dynamically adjust its length. This affects a number of details of the algorithms. There are other cases where there are variations to the array method algorithms necessary to deal with the potential spareness of regular arrays.

This is the case for several of the array methods but for many of them, the same algorithmic description can be used for both Arrays and Typed Arrays.  In those cases, the ES6 spec. doesn't duplicate the algorithm but instead the Typed Array method specification simply reference the corresponding Array method specification. For example: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%.prototype.foreach 

There was one issue I had to make a decision on.  In the cases where the same algorithm was applicable to both Array and typed Array should a single (same identify) function be used in both Array.prototype and %TypedArray%.prototype or should a distinct function be used for each.  I choose the latter because it seems to allow for more implementation flexibility.  There are lots of ways that some of these algorithms might be optimized if you know you are dealing with a typed array. I wanted to give implementations that option and the most straightforward way to do so is to simply say that, for example, Array.prototype.foreach and %TypedArray%.prototype.forEach are distinct function objects.  That way they can have distinct implementations.  However, if an engine whats to share the same implementation level code between the two functions it could still do that.