> 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). Otherwise I'd just keep passing `Infinity` as the third argument to my methods. Is it possible to detect infinite generators ahead of time? My intuition says no. > map and filter clearly would be very useful. I'm not sure about the others. Losing the others would be a shame. As I mentioned, much of the time I want to expose something with the semantics of an iterator, even if internally to my module or class I am storing the data as an array. So even if infinite generators cause problems for implementing `every` et al., the vast majority of real-world iterators would not be derived from infinite generators. Thus my above desire for the extra argument being optional. Currently in our codebase, we have a number of these methods (like `fetchAllProducts()`) that return `slice()`ed copies of internal arrays, since we don't want to expose the arrays directly. (Iterators would of course be the best solution here.) Over the course of 77K LOC, the only methods we don't use on the products collection are `join`, `reduceRight`, `reverse`, and `toString`. And we do use `join` on some of the simpler collections (`fetchProductTags()`). So they're all useful! -Domenic On Sat, Feb 4, 2012 at 10:06 PM, Michael A. Smith <mich...@smith-li.com> wrote: > 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 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 `IEnumerable<T>` or >> Java's `Iterable<T>`). ES Harmony seems to have the answer: iterators! Like >> `IEnumerable<T>` or `Iterable<T>`, they are the most basic primitive of >> iteration. Yay! >> >> But, if my `fetchAllProducts()` method returns an iterator, I don't get my >> array extras. Sad. >> >> --- >> >> This may be solvable in library-space, but the iterator proposal doesn't >> seem to have an Iterator.prototype I could extend. So we end up with >> unfortunate underscore-style wrappers: >> >> _(iterator).chain().map(mapper).some(predicate).value() >> _.some(_.map(iterator, mapper), predicate) >> >> I propose adding the array extras to any iterator (in some way), such that >> we can have syntax similar to the following: >> >> 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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
