Le 28/12/2013 20:24, Rick Waldron a écrit :
> On Sat, Dec 28, 2013 at 11:37 AM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     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.
Agreed. I was just trying to share what I felt the future taste like.

> 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.
Ok, I think I better understand what you meant by "can't be iterable".

>
>         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
Ok for userland objects, but do you have examples for platform objects? 
I feel that it's up to the W3C folks to add appropriate @@iterators to 
the objects they define... and it's already the case with indexed 
getters for instance [1]. (Firefox has already implemented it, you can 
for-of the result of qSA \o/).
I wonder what you mean by "behave correctly on platforms with and 
without @@iterator". If you're targetting both types of platforms, you 
can't use the new facilities (for-of and spread), so you don't need for 
your objects to adhere to the iterable protocol.

> (ie. browsers that have large market share but don't auto-update).
I already see IE10 market share being higher than IE9. IE8 might be the 
last browser without symbols

> `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)
Why can't the code that only run in ES6 provide its own "make iterable" 
facility? As you said, it's polyfillable. I think spread is even 
"compile-to-ES3"-able.

> 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.
What you're indirectly saying here is that Array.from is not useful in 
an ES6-only code base (since @@iterator+spread can be used).
Libraries (Array._from?) and tooling (compile spread to ES3) can be 
enough for the transition, no?

David

[1] http://heycam.github.io/webidl/#es-iterators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/465391cb/attachment-0001.html>

Le 28/12/2013 20:24, Rick Waldron a écrit :
> Realistically, this is a minority use case.

Agreed. I was just trying to share what I felt the future taste like.

> 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.

Ok, I think I better understand what you meant by "can't be iterable".

> 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

Ok for userland objects, but do you have examples for platform objects? 
I feel that it's up to the W3C folks to add appropriate @@iterators to 
the objects they define... and it's already the case with indexed 
getters for instance [1]. (Firefox has already implemented it, you can 
for-of the result of qSA \o/).
I wonder what you mean by "behave correctly on platforms with and 
without @@iterator". If you're targetting both types of platforms, you 
can't use the new facilities (for-of and spread), so you don't need for 
your objects to adhere to the iterable protocol.

> (ie. browsers that have large market share but don't auto-update).

I already see IE10 market share being higher than IE9. IE8 might be the 
last browser without symbols

> `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)

Why can't the code that only run in ES6 provide its own "make iterable" 
facility? As you said, it's polyfillable. I think spread is even 
"compile-to-ES3"-able.

> 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.

What you're indirectly saying here is that Array.from is not useful in 
an ES6-only code base (since @@iterator+spread can be used).
Libraries (Array._from?) and tooling (compile spread to ES3) can be 
enough for the transition, no?

[1]: http://heycam.github.io/webidl/#es