Add count method

[sea1jxr]

I was really wishing I had count today, while using genSequence so I added it.

[coveralls]

Coverage remained the same at 100.0% when pulling a935826 on sea1jxr:count into 7c2a4e3 on Jason3S:master.

[Jason3S]

Sorry about not getting back to you sooner on this one.

Nicely done with the code.

I have a concern that has nothing to do with your code. The .count() will consume the iterator. If the iterator is an array, you can re-use it. But it is not re-usable if the iterator came from a generator.

[Jason3S]

I think your code is fine, I am just worried about confusion generated because someone doesn't understand why the sequence was consumed.

[Jason3S]

Nicely done. There is two more tests necessary.
Need to test the behavior of what happens if the sequence is used again after .count().

Example:

const values = [1, 2, 3, 4, 5, 6]
const seq = genSequence(values);
const cnt = seq.count();
const cntAgain = seq.count();

and

const values = [1, 2, 3, 4, 5, 6]
const seq = genSequence(values).filter(a => !!(a % 2));
const cnt = seq.count();
const cntAgain = seq.count();

[sea1jxr]

.NET has the same issue with IEnumerables and LINQ, but they allow it, and many times the sequence can handle a reuse.

[coveralls]

Coverage remained the same at 100.0% when pulling 73ffd5c on sea1jxr:count into 7c2a4e3 on Jason3S:master.

[sea1jxr]

I made sequences reusable. I ended up removing the next() method because the iterator needed to be reset after it saw done. I thought maybe that was a bad practice, but the spec doesn't seem to prohibit it, so if there are good scenarios for next() we could bring it back for reusable sequences.

This was kind of an experiment to see if I could make them reusable. It turned out well, so I thought I would run it by you.

Let me know what you think.

[Jason3S]

Wow. Very cool.
You have made it late binding. Similar to RxJs.
I need a bit more time to think about the implications.

I think your suggestion is worth exploring. I will have to bump the major version number, since it is a change to the underlying behavior.

Typing and thinking at the same time (not a good combo for me):

• I think .next() is necessary to meet the iterator spec and removing it might break some stuff (not sure).

[coveralls]

Coverage remained the same at 100.0% when pulling 30b5bcc on sea1jxr:count into 7c2a4e3 on Jason3S:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 5eaa9dc on sea1jxr:count into 7c2a4e3 on Jason3S:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 5eaa9dc on sea1jxr:count into 7c2a4e3 on Jason3S:master.

[sea1jxr]

I added back .next(). Take your time and think through the scenarios.

[coveralls]

Coverage remained the same at 100.0% when pulling 1c1b7b3 on sea1jxr:count into 7c2a4e3 on Jason3S:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 1c1b7b3 on sea1jxr:count into 7c2a4e3 on Jason3S:master.