Skip to content
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

Consider other solutions for Iterables... #159

Open
javagl opened this issue Nov 24, 2024 · 0 comments
Open

Consider other solutions for Iterables... #159

javagl opened this issue Nov 24, 2024 · 0 comments

Comments

@javagl
Copy link
Contributor

javagl commented Nov 24, 2024

The current Iterables class has been created to offer basic utility functions for iteration. These should have been part of the core language specification since the Iterator concept was established, but ... haven't. Given some possible upcoming refactorings (e.g. in the context of #156 ), the same functionalities will also be required for asynchronous iterators.

There are several options for the "other solutions" mentioned in the title:

  • Replacing that class with a library dependency
  • Extracting it into a library/package
  • Replacing it with built-in functionalities

The last one would be the most desirable. And it looks like in the meantime (roughly a month ago), https://github.com/tc39/proposal-iterator-helpers has been brought on its way to become part of the core standard (but who knows how long that will take). That won't be enough, though: We'd still have to wait for https://github.com/tc39/proposal-async-iterator-helpers ...

There certainly are dozens of existing libraries that offer similar functionality, and much (MUCH) more that could be useful here. (and ... are better tested). Some of them are listed in https://github.com/tc39/proposal-iterator-helpers?tab=readme-ov-file#prior-art--userland-implementations . But a built-in solution would be preferable in many ways (particularly because it's not clear when and how these libraries will catch up with asnychronous iteration protocols...)


Note: When looking at the functions in Iterables, one might wonder why they are written in this seemingly complicated way of always creating a resultIterable ... [Symbol.iterator] ... Some of the "boilerplate" code there could be avoided (with some private static createIterator(...) function or so). But the underlying issue here is that a JavaScript Generator concept is ... well, I'll just call it "broken": It is an iterator that looks like an iterable. But it is iterable only once:

function* create() {
  yield "ELEMENT0001";
  yield "ELEMENT0002";
  yield "ELEMENT0003";
  yield "ELEMENT0004";
}

function example() {

  const iterable = create();

  console.log("Let's iterate, because it's iterable");
  for (const element of iterable) {
    console.log(element);
  }

  console.log("Let's try that again, because it's iterable");
  for (const element of iterable) {
    console.log(element);
  }
  console.log("Whoopsie, why didn't it show anything?");
}

example();

In order to have something that is truly iterable, one has to create the Generator==Iterator each time when an iterator is requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant