Array extras functionality for iterators

Michael A. Smith michael at smith-li.com
Sat Feb 4 15:30:17 PST 2012


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
<domenic at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list