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.map(someFunction); // guarantees an array result, cannot be lazy vs (someFunction(someVeryLargeArray(i), i, someVeryLargeArray) for (i in someVeryLargeArray)) // Lazy, likely to perform better in some important cases. I think there's a case to be made for direct implementations of such methods. Something like someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable (No apologies to the email protocol.) What do you think? -Michael A. Smith On Fri, Feb 3, 2012 at 3:54 PM, Domenic Denicola <dome...@domenicdenicola.com> wrote: > > iterator.map(mapper).some(predicate) // returns an iterator > > The methods I would like to see are: > * every, filter, forEach, map, reduce, reduceRight, some > * Optionally: join, toString > * Controversially: sorted, reversed (non-mutating versions of sort and > reverse) > > What do you think? > > -Domenic > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
