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

Rename to Iterator.ofNumbers? #58

Closed
Jack-Works opened this issue Aug 23, 2022 · 7 comments
Closed

Rename to Iterator.ofNumbers? #58

Jack-Works opened this issue Aug 23, 2022 · 7 comments

Comments

@Jack-Works
Copy link
Member

Iterator helpers try to advance to stage 3 next meeting. If we rename this proposal to Iterator.ofNumbers, we can solve our current problem.

Not Iterator.range because I think there might be something like Iterator.ofChars in the future.

If we can rename it to Iterator.ofNumbers, I'll try to move this proposal forward with the current semantics (maybe with some simplification).

@ljharb
Copy link
Member

ljharb commented Aug 23, 2022

What current problem would that solve?

@Jack-Works
Copy link
Member Author

What current problem would that solve?

The name does not hint it is an iterator that can only be used once?

@ljharb
Copy link
Member

ljharb commented Aug 23, 2022

"it's an iterator" and "generators" should already hint that. Is that the primary source of objection from those who want something reusable, the name? I was under the impression that they wanted reusability, not that there was naming confusion.

@hax
Copy link
Member

hax commented Dec 3, 2022

@ljharb Even many people (include me) prefer reusable "range" due to various reasons, I don't think there is a very strong objection to a iterator/generator version if the API name is clear and don't cause confusion and misuse. I already suggest this direction in #57 .

@hax
Copy link
Member

hax commented Dec 3, 2022

I support renaming, but I also suggest we could consider only support integers, so the name will be Iterator.ofIntegers, because:

  • the main use cases is iterating integers
  • accumulate floating points always have precision problem which surprise the devs
  • supporting floating points require a slightly complex algorithms

Even if we still want to support floating points, ofNumbers seems not fit because Number should not include bigints.

@Andrew-Cottrell
Copy link

Andrew-Cottrell commented Dec 3, 2022

  • accumulate floating points always have precision problem which surprise the devs

The spec avoids accumulated floating-point error by using the following

18.j.i. Let currentYieldingValue be start + (step * currentCount).

where currentCount is a non-negative integer.

  • supporting floating points require a slightly complex algorithms

I suggest any additional slight complexity is worthwhile as there are use cases (e.g., plotting charts & graphs, examining mathematical functions, producing test data) where it might be expected that a floating-point range function would a natural tool to use. We can use bijective transformations to & from integer coordinates (and might do so when plotting to a raster graphic), but these transformations increase conceptual complexity if they would not otherwise be necessary (to the extent that one might locally implement a floating-point range function instead of directly using Iterator.ofIntegers).

Even if we still want to support floating points, ofNumbers seems not fit because Number should not include bigints.

Agreed.

@zloirock
Copy link
Contributor

zloirock commented Dec 3, 2022

It's logical to have iteration methods on iterated types, otherwise, we will have Iterator.ofStrings, Iterator.ofDates, and tenths other methods that don't belong here - it's like move Array or Set iterators to this namespace. It's better to revisit #59.

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

5 participants