New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 1.0 #5
Comments
It is desirable that given an
|
|
In order to implement this, almost built-in iterables has
function* entries () {
let index = 0
for (let val of iterable) {
yield [index, val]
++index
}
} Then, all of Iterum methods that use callbacks ( |
Problems implementing methods based on entriesGiven the following sentence: const iterable = Iterum(new Map([['one', 1], ['two', 2]])).concat(new Map([['one', 5], ['three', 3]]))
const index = iterable.findIndex(e => e === 5) // returns 'one'
iterable.slice('one') // returns iterable -> because the first key is also 'one' Therefore, I think that is better go back and implement Iterum instances that behaves like an array with numeric indexes. |
Iterum aims to provide array-like methods emulating the behaviour of arrays in iterables but using lazy evaluation. However this approach is only possible imitating methods that return an array. For example, given methods of Array that return an array (map, filter, concat, slice) can be replicated in Iterum class like a methods that return Iterum instances. But imitating array methods that return other values (reduce, indexOf, find, etc) is not possible to do chaining and, then, lazy evaluation is also not possible. For that, I think that is important increase the list of Iterum methods that return another iterable. I think that the good example is keeping the same nomenclature than For example: const iterumDropWhile = iterum.dropWhile(cb, context) is the lazy version of: const index = iterum.findIndex((e, i, itm) => !cb(e, i, itm), context)
const iterumDropWhile = iterum.slice(index)
is the lazy version of: const index = iterum.findIndex(cb, context)
const iterumTakeWhile = iterum.slice(0, index) |
|
Currently, an Iterum iterable that produces some Iterum value is expanded automatically. For example: const iterable = Iterum([1, Iterum([2, 3, 4]), 5])
[...iterable] // returns [1, 2, 3, 4, 5] and not [1, Iterum([2, 3, 4]), 5] I think that this behaviour is weird by default. I think that is preferable that Iterum instances does not have privileges over other iterables. If is required to expand an iterable inside other iterable, it is possible to use something like flatten lodash function. Then, |
Which is the criteria to decide if a method has static implementation or not? For example, Iterum([1, 2]).cartesian([3, 4]) // potentially [[1, 3], [1, 4], [2, 3], [2, 4]] Actually, all of object methods can be transformed to static methods. Instead all static methods cannot be tranformed to object methods (see |
I would like to implement a new release using ES2015 features.
The current package just allows manipulate generators with 0-arity. There are some similar data structure in es2015: iterables
Iterables are objects that wraps a generator of 0-arity in Symbol.iterator property. Then:
Iterum(generator)
constructor will be deprecated andIterum(iterable)
will be the new constructor.Iterum
instance will also be an iterable.Then, new branch dev-1.0 has been created and I will be happy to receive any suggestions and constributions.
Thanks.
The text was updated successfully, but these errors were encountered: