feature proposal: iterable interfaces

[derhuerst]

trafficstars

Using iterables to walk over a large amount of items/data has two advantages:

• In contrast to computing a full array all items, items can be read from the tree on the fly. This prevents unnecessary graph walks.
• Iterables are well-supported within ECMAScript and libs: String, Array, Map, Set etc. are iterable.

Examples of how iterables would be useful for this lib:

for (const key of tree.keys()) {
  await userRequestedAKey()
  console.log(key)
}

for (const node of tree.range('A', 'O')) {
  console.log(node.data)
}

[derhuerst]

I'd be happy to submit a PR with this!

[w8r]

Please do! Would that still be es5 compatible?

[derhuerst]

Would that still be es5 compatible?

Nope, Symbol.iterator is ES2015/ES6, so not supported in IE11.

But I think you can implement it in a backwards-compatible way:

if (Symbol && Symbol.iterator) {
  AVLTree.prototype[Symbol.iterator] = function (...) {...}
}

[w8r]

That would be cool!

[derhuerst]

What API do you prefer?

1. tree is not iterable
2. tree[Symbol.iterator] returns a keys iterable?
3. tree[Symbol.iterator] returns an entries ([key, value]) iterable?

---

1. tree.keys() stays an array as before, add tree.keysIterable().
2. Change tree.keys() from an array to an iterable. (breaking)

same for tree.values()

[w8r]

3. tree[Symbol.iterator] returns an entries ([key, value]) iterable?

---

1. tree.keys() stays an array, as before, add tree.keysIterable()

right?

[derhuerst]

Okay, will implement this. A tree.valuesIterable() also makes sense, right?

[w8r]

yes, let's do it like that. Maybe I will change the API later. I will also add your changes to the splay-tree repo then

[derhuerst]

I have implemented this at derhuerst/avl#iterables, but using ES6 generators. They are not supported in IE11, so we have two choices now:

1. implement the iterators by hand using only ES5 syntax,
2. or use Babel for transpiling or get bublé to transpile generators.

What do you prefer?

[derhuerst]

Opted for 1.