I believe that Array.from's only purpose is to provide guidance for polyfills for people to use in ES3/ES5 code; nobody writing ES6 would ever use it. In essence it's saying "TC39 likes es6-shim more than Underscore, and is helping tell them what should be in it, with the hope that people use it." At least, that's what it seems to me. ________________________________ From: David Bruant<mailto:[email protected]> Sent: 12/28/2013 17:28 To: Rick Waldron<mailto:[email protected]> Cc: Brendan Eich<mailto:[email protected]>; EcmaScript<mailto:[email protected]> Subject: Re: Overly complicated Array.from?
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
