Catching up on this discussion.
Personally, I'd like to see us come to quick consensus on `forEach` for
collections, because without something like `forEach`, it's impossible to
implement useful versions of these collections in user-space in browsers
that do not implement for-of.
Indeed, the
On Tue, Feb 28, 2012 at 12:06 PM, Yehuda Katz wyc...@gmail.com wrote:
Catching up on this discussion.
Personally, I'd like to see us come to quick consensus on `forEach` for
collections, because without something like `forEach`, it's impossible to
implement useful versions of these
ES5's existing array extras make working with arrays a joy.
However, sometimes arrays are not the right tool for the job. Perhaps you want
lazy evaluation semantics (generators). Or perhaps you want to communicate that
the list is immutable (compare .NET's `IEnumerableT` or Java's
Sorry for the resend. Meant to include the list.
I like this idea a lot! However, what would be the correct behavior of
a method like 'every' on an infinite generator?
-Michael A. Smith
On Fri, Feb 3, 2012 at 3:54 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
ES5's existing array
I'd say every and other methods like that should take another argument
that specifies the number if times to test.
You could say that every returns:
- true if the generator is finite and the function always returned true
- false if one of the finite (either because the generator is or
because a
I'd say every and other methods like that should take another argument that
specifies the number if times to test.
This seems reasonable. Preferably that parameter would be optional, since the
majority of the time my iterators will not be derived from infinite generators
(and I know this).
Has anyone checked out or used
http://docs.python.org/py3k/library/itertools.html ? Seems worth
considering since ES6 generators are derived from Python generators.
Indeed, there's no way to detect an infinite generator ahead of time.
Some array extras do not make sense even for very large
On a related note, there are many ways in which some of these methods
would overlap with the capabilities of array comprehensions and
generator expressions. As far as I can tell, the one thing you cannot
do (with, say, map) is take an array as input and process it lazily.
For example:
someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable
How about `someVeryLargeArray.asIterator().map(someFunction)`?
-Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
9 matches
Mail list logo
