Release 1.0 about iterum

[xgbuils]

It is desirable that given an iterable:

• Iterum(iterable) behaves like iterable with for...of and spread operator.
• callback of Iterum(iterable) methods (map, filter, some, etc) traverse the same value and key that forEach method of built-in javascript iterables.

[xgbuils]

Repeat constructor will be deprecated and a .repeat() method with signature similar to String.prototype.repeat will be implemented.

[xgbuils]

• callback of Iterum(iterable) methods (map, filter, some, etc) traverse the same value and key that forEach method of built-in javascript iterables.

In order to implement this, almost built-in iterables has .entries() that returns an iterable that iterates throw [key, values].

• In Map, these values are the keys and values of the Map instance.
• In Array, TypedArray, the keys are the indexs.
• In Set, the keys and values are the same

Iterum(iterable) will have a method .entries that returns the same iterable as iterable.entries(). If iterable does not have method entries (String), then default entries will be implemented like that:

    function* entries () {
        let index = 0
        for (let val of iterable) {
            yield [index, val]
            ++index
        }
    }

Then, all of Iterum methods that use callbacks (map, filter, some, etc) will be implemented using .entries method to be consistent.

[xgbuils]

Problems implementing methods based on entries

Given the following sentence:

const iterable = Iterum(new Map([['one', 1], ['two', 2]])).concat(new Map([['one', 5], ['three', 3]]))

• methods with callbacks iterates over keys with the same value.
• Method indexOf has weird behaviour:

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.

[xgbuils]

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 lodash methods. In order to expand the ecosystem of methods, it's interesting to implement dropWhile, takeWhile, drop and take.

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)

const iterumTakeWhile = iterum.takeWhile(cb, context)

is the lazy version of:

const index = iterum.findIndex(cb, context)
const iterumTakeWhile = iterum.slice(0, index)

[xgbuils]

Iterum.compose it is useful function that is used to compose generators and lazy implementation of cartesian product of iterables (Iterum.cartesian) and also is used in other packages like siteswap-generator. However the new iterum package works with iterables and not generators. Then this function should be extracted to another package.

[xgbuils]

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, Iterum autoexpandability should be removed and flatten method should be created.

[xgbuils]

Which is the criteria to decide if a method has static implementation or not?

For example, cartesian is a static methods that allows iterable instances. However it is possible to create a method like that:

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 range static method). Then, as I don't find criteria to decide if method should be static or not, any object method will have its corresponding static method and the user is free to choose what to use.