Re: Overly complicated Array.from?
Le 26/12/2013 05:00, Rick Waldron a écrit : On Wed, Dec 25, 2013 at 7:33 PM, David Bruant For the rationale, the wiki states [1]: There are many array-like objects in JS (arguments objects, DOM NodeLists, arrays from separate windows, typed arrays) and no simple way to convert one of these to an instance of Array in the current window; this is the rationale behind a simple conversion function (Array.from). I think that if all of these objects had a good default @@iterable, there wouldn't be a need for the array-like part of Array.from. The good default most likely being based on .length, etc. The array-like part is for all of those objects that _won't_ have an @@iterator, for one reason or another I must have missed these reasons. No @@iterator also means these objects cannot be iterated with via for-of loops by default and I can't think of a good reason for that for any of the listed (arguments, NodeList, arrays from different windows, typed arrays). Do you have a link to previous discussions on this topic or a summary if that can be explained quickly? and for useful shimming in ES5 runtimes. Even if Array.from relies on @@iterator for runtimes with symbols, it doesn't prevent runtimes without symbols to embed the iterator logic in the Array.from source (which is exactly what your prolyfill does). David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 82, Issue 98
-- Forwarded message --
From: Brendan Eich bren...@mozilla.com
To: raul mihaila raul.miha...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Date: Wed, 25 Dec 2013 13:44:21 -0500
Subject: Re: Fwd: local variables with inherited values
That's unusual -- why would it take on the out same-named variable's
value? Note it won't work for 'const', only 'let'. Is there any difference
for 'let' between your proposal and A2, lexical window? Let's see, by
simplifying the example to make the inner 'const x' into a 'let x':
I misinterpreted Waldemar Horwant's cases. There's no difference between
my proposal and A2 + B2, besides a possible way to make it more readable.
In any case, we aren't adding another keyword, and your approach does not
work for 'const' at all. For 'let' or any new keyword, it hoists and
implicitly initializes, which is too implicit and magical, even for JS.
You're right, it wouldn't work for const.
It's far less readable, though, because of the implicit magic
initialization from outer shadowed x. What if there is no outer x? And
'const' does not work at all. We can't have two values for a given 'const'
binding.
I agree, if there's no way to make it more readable, it will be too magical
and bad. (BTW, throw if there's no outer x.) I am beginning to like the
syntax from ES4. I suppose it would work with multiple variables as well.
let (x = x, y = y, z = x + y /* maybe would work? */) {
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
Le 26/12/2013 10:58, David Bruant a écrit :
Le 26/12/2013 05:00, Rick Waldron a écrit :
On Wed, Dec 25, 2013 at 7:33 PM, David Bruant
For the rationale, the wiki states [1]:
There are many array-like objects in JS (arguments objects, DOM
NodeLists, arrays from separate windows, typed arrays) and no
simple way to convert one of these to an instance of Array in the
current window; this is the rationale behind a simple conversion
function (Array.from).
I think that if all of these objects had a good default
@@iterable, there wouldn't be a need for the array-like part of
Array.from.
The good default most likely being based on .length, etc.
The array-like part is for all of those objects that _won't_ have an
@@iterator, for one reason or another
I must have missed these reasons. No @@iterator also means these
objects cannot be iterated with via for-of loops by default and I
can't think of a good reason for that for any of the listed
(arguments, NodeList, arrays from different windows, typed arrays).
Do you have a link to previous discussions on this topic or a summary
if that can be explained quickly?
Found the relevant part of the notes [1]:
BE: Let's not remain slaves to legacy, Array.from, for-of and spread
use only iterable.
RW: What about pre ES6 environment?
BE: Can fall back to array-like if needs.
I guess this is where I differ as I don't see a need. In ES5
environments, the default @@iterator can be embedded in Array.from,
leading to something like (worst case for explanatory purposes):
js
Array.from = function(x){
if(/*x is a NodeList*/){
// polyfill default NodeList[@@iterator] behavior to create the
array to return
}
if(/*x is an Arguments*/){
// polyfill default Arguments[@@iterator] behavior to create
the array to return
}
// ...
}
Most likely all of these @@iterator polyfills are the same array-like
traversals, so there shouldn't be a need to separate each case, they
most likely all use the same logic.
Rick Waldron:
The array-like part is for all of those objects that _won't_ have an
@@iterator, for one reason or another
The Conclusion/Resolution section of [1] suggests: Add iterator
protocol to arguments object (should exist on all things.
I went quickly through all the meeting notes I could find and didn't
find something about some objects not having an @@iterator.
David
[1]
https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#revisit-nov-27-resolution-on-iterables-in-spread
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 82, Issue 98
raul mihaila wrote:
I am beginning to like the syntax from ES4. I suppose it would work
with multiple variables as well.
let (x = x, y = y, z = x + y /* maybe would work? */) {
}
Yes, ES4 let expr/block works with multiple declarators in a
comma-separated list in the head. Perhaps it will be re-championed for
ES7, but we need to get basic let/const/class and function-in-block
fully baked first.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
