Allen Wirfs-Brock (2014-02-21T18:54:45.000Z)
Also see https://bugs.ecmascript.org/show_bug.cgi?id=2416 

On Feb 21, 2014, at 8:13 AM, medikoo wrote:

> Currently per spec Array.from doesn't produce perfect copies of sparse
> arrays:
> 
> Array.from([1,,2]); // [1, undefined, 2]
> 
> I know it's been discussed [1] but there's not much feedback.
> 
> It doesn't seem right for a few reasons:
> 
> 1. Array.from already produces sparse arrays from array-likes:
> 
> Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
> 
> So why it doesn't from sparse arrays?

Perhaps, this is an inconsistency that should be corrected by changing the spec. to produce [1,2,undefined] in the above case. 

The current definition was derived from the legacy algorithms such as A,p.slice which preserve holes.  But as the current consensus is Array.from does not preserve hole for Iterable arrays then perhaps is also should preserve them for non-iterable array-likes,

> 
> 2. Array.from can't be used as generic plain array copy producer.
> 
When this was most recently discussed at [1] the case was made that in JS sparseness is seldom what anybody actually wants, hence the current Array.from behavior will be what's desired most of the time.  Do you have any real world use cases in mind that are driving the desire for Array.from to preserve sparseness?


> In ES5 this can be achieved, with `arr.slice()`. However as in ES6 `slice`
> will return object of same type as one on which it is called, so it is no
> longer that straightforward, especially if we're strongly after plain array.

On the other hand it is fairly straightforward to define:

class SparseArray extends Array {
   static from(collection) { ... /* over-ride to preserve holes */}
   *keys() {for (let k of super.keys()) if (Object.hasOwnProperty(this,k)) yield k}
   *entries() {for (let [k,v] of super.entries()) if (Object.hasOwnProperty(this,k)) yield [k,v]}
}

> 
> The only 100% bulletproof solutions we have in ES6 are either:
> 
> var plainCopy = new Array(arr.length)
> arr.forEach(function (v, i) { plainCopy[i] = v; });
> 
> or other quite dirty way:
> 
> Array.from(Object.assign({ length: arr.length}, arr));
> 
> Other related question:
> 
> Why do array iterators go through not defined indexes? It seems not
> consistent with other iteration methods we have since ES5, are there any
> plans to use sparse iteration kinds [2] or are they defined just to reserve
> eventual future use?

That's an rement that is now gone.  When I first define Array Iterators I allowed for the possibility of doing sparse iterations.  However, there was no public API for doing so and nobody ever proposed or strongly advocated for one the spare iteration support was removed from the spec. The mention of spare iteration in Table 42 is something I originally missed removing, but it's now gone.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140221/6d7d8853/attachment.html>
domenic at domenicdenicola.com (2014-03-02T22:40:43.767Z)
Also see https://bugs.ecmascript.org/show_bug.cgi?id=2416 

On Feb 21, 2014, at 8:13 AM, medikoo wrote:

> 1. `Array.from` already produces sparse arrays from array-likes:
> 
>    ```js
>    Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
>    ```
>    So why it doesn't from sparse arrays?

Perhaps, this is an inconsistency that should be corrected by changing the spec. to produce `[1,2,undefined]` in the above case. 

The current definition was derived from the legacy algorithms such as A.p.slice which preserve holes.  But as the current consensus is Array.from does not preserve hole for Iterable arrays then perhaps is also should preserve them for non-iterable array-likes,

> 
> 2. Array.from can't be used as generic plain array copy producer.
> 

When this was most recently discussed at [1](https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-28.md#arrayfrom) the case was made that in JS sparseness is seldom what anybody actually wants, hence the current Array.from behavior will be what's desired most of the time.  Do you have any real world use cases in mind that are driving the desire for Array.from to preserve sparseness?


> In ES5 this can be achieved, with `arr.slice()`. However as in ES6 `slice`
> will return object of same type as one on which it is called, so it is no
> longer that straightforward, especially if we're strongly after plain array.

On the other hand it is fairly straightforward to define:

```js
class SparseArray extends Array {
   static from(collection) { ... /* over-ride to preserve holes */}
   *keys() {for (let k of super.keys()) if (Object.hasOwnProperty(this,k)) yield k}
   *entries() {for (let [k,v] of super.entries()) if (Object.hasOwnProperty(this,k)) yield [k,v]}
}
```

> are there any
> plans to use sparse iteration kinds [2] or are they defined just to reserve
> eventual future use?

That's an rement that is now gone.  When I first define Array Iterators I allowed for the possibility of doing sparse iterations.  However, there was no public API for doing so and nobody ever proposed or strongly advocated for one the spare iteration support was removed from the spec. The mention of spare iteration in Table 42 is something I originally missed removing, but it's now gone.