Le 28/12/2013 20:24, Rick Waldron a écrit :
On Sat, Dec 28, 2013 at 11:37 AM, David Bruant <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
