On Sat, Dec 28, 2013 at 11:37 AM, David Bruant <bruant.d at gmail.com> wrote:

> Le 28/12/2013 15:25, Brendan Eich a écrit :
>
>  This seems overcomplicated. Isn't the likelier code something like
>>
>>   Array.from || (Array.from = function(b) { var a=[]; for (var i=0;
>> i<b.length; i++) a.push(b[i]); return a; });
>>
>> Isn't the whole point to impute arraylikeness to the parameter?
>>
> In any case the important point is that it's possible to implement in an
> ES5 env whatever behavior is expected from Array.from in an ES6 env.
>
>
>  Granted, it's not super elegant solution, but it does work. The overhead
>>> becomes significant only in the degenerate cases where dozens of libraries
>>> override Array.from.
>>>
>>
>> David, I took your side in the TC39 meeting, as the meeting notes
>> disclosed. Rick prevailed (I think, my memory is hazy).
>>
> It's what I read from the notes too, but I feel something may have been
> overlooked.


>  You want the polyfillers to pay the price, while Rick proposes that ES6's
>> built-in absorb arraylike fallback handling.
>>
>> The difference is not in the polyfill (old browser) case, but in the
>> present and future (ES6 and above) cases: some objects will remain
>> arraylike yet lack @@iterator.
>>
> In ES6 and above, why would one create such an object? What's a good use
> case?
> My understanding of the current consensus is that an arraylike without
> @@iterator wouldn't work for for-of loops nor spread. Why not just create
> an array? jQuery and Zepto want to subclass Array (one creates arraylike,
> the other does subclass setting __proto__). It wasn't possible in ES5, but
> is in ES6 with classes (and the super+@@create infrastructure).
>

jQuery is a bad example to use in this case, because it will _never_
include features that can't be made to work consistently across all
platforms that are supported. This includes jQuery 2.x, which has no less
and no more features or capabilities than jQuery 1.x (and never will).


>
> I feel that all the cases that justified arraylikes in the past have much
> better alternatives in ES6.
> My little experience building a Firefox addon even suggests that sets
> replace arrays in most situations as most of what I do with arrays is
> .push, for-of and .map/filter/reduce (by the way, Set.prototype needs these
> too, but another topic for another time).


Realistically, this is a minority use case. The most common use case is a
web-based application that often must work on platforms as old as IE8, and
that shouldn't _limit_ the progress and evolution in ES6 features.


>
>
>  Why shouldn't Array.from help them out?
>>
> If these objects have a good reason to exist in an ES6 and above world, I
> agree, that's a good point. But is there a use case justifying their
> existence?


In the ES6 world, there will be userland and platform objects that can't be
upgraded to real iterables, eg. application code that must behave correctly
on platforms with and without @@iterator (ie. browsers that have large
market share but don't auto-update). Array.from can be shimmed such that
code like the following will work correctly on both older ES3-5
(Array.prototype methods shimmed for ES3) or ES6 platforms:

  if (typeof Array.from === "undefined") {
    ...shim it.
  }

  function f() {
    // Works correctly on browsers that have implemented @@iterator on
arguments objects
    // as well as those that have not.
    return Array.from(arguments).map(...);
  }

  // Or...

  // Works correctly on browsers that have implemented @@iterator on
NodeList objects
  // as well as those that have not.
  Array.from(qSA(".selector")).forEach(...);



`for-of` won't even exist on these older platforms, but for code that only
needs to run on ES6 platforms, Array.from provides a "spread" or "make
iterable" mechanism for those objects that _can't_ be upgraded (for any
reason, as noted above):

  // Turn a jQuery object into an iterable:
  Array.from(jQuery(".selector"));

(This can't be done with spread)

Array.from bridges the gap between ES3/5 and ES6 while remaining useful in
an ES6 and post ES6 world by providing an "assimilation" path for objects
that have pre-existing constraints.


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/ae0a8147/attachment.html>

On Sat, Dec 28, 2013 at 11:37 AM, David Bruant <bruant.d at gmail.com> wrote:

> In ES6 and above, why would one create such an object? What's a good use
> case?
> My understanding of the current consensus is that an arraylike without
> @@iterator wouldn't work for for-of loops nor spread. Why not just create
> an array? jQuery and Zepto want to subclass `Array` (one creates arraylike,
> the other does subclass setting `__proto__`). It wasn't possible in ES5, but
> is in ES6 with classes (and the super+@@create infrastructure).

jQuery is a bad example to use in this case, because it will _never_
include features that can't be made to work consistently across all
platforms that are supported. This includes jQuery 2.x, which has no less
and no more features or capabilities than jQuery 1.x (and never will).


> I feel that all the cases that justified arraylikes in the past have much
> better alternatives in ES6.
> My little experience building a Firefox addon even suggests that sets
> replace arrays in most situations as most of what I do with arrays is
> .push, for-of and .map/filter/reduce (by the way, Set.prototype needs these
> too, but another topic for another time).


Realistically, this is a minority use case. The most common use case is a
web-based application that often must work on platforms as old as IE8, and
that shouldn't _limit_ the progress and evolution in ES6 features.


> If these objects have a good reason to exist in an ES6 and above world, I
> agree, that's a good point. But is there a use case justifying their
> existence?


In the ES6 world, there will be userland and platform objects that can't be
upgraded to real iterables, eg. application code that must behave correctly
on platforms with and without @@iterator (ie. browsers that have large
market share but don't auto-update). Array.from can be shimmed such that
code like the following will work correctly on both older ES3-5
(Array.prototype methods shimmed for ES3) or ES6 platforms:

```js
  if (typeof Array.from === "undefined") {
    ...shim it.
  }

  function f() {
    // Works correctly on browsers that have implemented @@iterator on arguments objects
    // as well as those that have not.
    return Array.from(arguments).map(...);
  }

  // Or...

  // Works correctly on browsers that have implemented @@iterator on NodeList objects
  // as well as those that have not.
  Array.from(qSA(".selector")).forEach(...);
```

`for-of` won't even exist on these older platforms, but for code that only
needs to run on ES6 platforms, `Array.from` provides a "spread" or "make
iterable" mechanism for those objects that _can't_ be upgraded (for any
reason, as noted above):

```js
// Turn a jQuery object into an iterable:
Array.from(jQuery(".selector"));
```

(This can't be done with spread)

Array.from bridges the gap between ES3/5 and ES6 while remaining useful in
an ES6 and post ES6 world by providing an "assimilation" path for objects
that have pre-existing constraints.