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

Iterating on the API Design #19

Closed
codehag opened this issue Mar 26, 2020 · 6 comments
Closed

Iterating on the API Design #19

codehag opened this issue Mar 26, 2020 · 6 comments

Comments

@codehag
Copy link

codehag commented Mar 26, 2020

One thing that stands out to us is that this is being implemented per number type. We are wondering what the use case would be for bignumber, or indeed for bigDecimal. Perhaps rather than having this as a method on number types, this can live somewhere else. One suggestion was to provide a NumberRangeIterator and if necessary a BigIntRangeIterator. Another thought was that this isn’t really about numbers, but about producing lists. So in this case it might make sense as a method on array, on Iterator, or something similar. We think that this can be made clearer by a better understanding of the use cases for this.

@ljharb
Copy link
Member

ljharb commented Mar 26, 2020

See also, array.build

@Jack-Works
Copy link
Member

One suggestion was to provide a NumberRangeIterator and if necessary a BigIntRangeIterator.

It is possible to move to Iterator.range

@Andrew-Cottrell
Copy link

Andrew-Cottrell commented Jun 15, 2020

It is possible to move to Iterator.range

It is viable to implement a range function for any partially ordered type so it may be considered preferable for all range functions to be namespaced by their corresponding type and to not special-case any single range function (even if it were the only built-in range function).

// assuming enumerable types default to inclusive-inclusive ranges
String.range("a", "z").next().value === "a";
RgbColor.range([16, 16, 16], [235, 16, 16]).next().value[0] === 16;
Month.range(Month.JANUARY, Month.DECEMBER).next().value === Month.JANUARY;

@codehag
Copy link
Author

codehag commented Mar 16, 2023

There is an issue with one of the suggestions that I made here (2020 eh) -- Iterator doesn't exist in the language as a builtin. I think the intention here was on the iterator prototype? That said in our current discussion we are not against Number.range() etc.

@ljharb
Copy link
Member

ljharb commented Mar 16, 2023

The Iterator Helpers proposal exposes it as a global.

@Jack-Works
Copy link
Member

Now we throw for non-number/bigint inputs for Iterator.range, which leaves future space if we want to support other data types.

It is viable to implement a range function for any partially ordered type

Yes, that's possible for other languages like Swift or Rust, but in JavaScript, we don't have Ord, PartialOrd, Eq protocols/traits/interfaces on day 1 and it looks like it will also not happen in the future...

I'm closing this issue for housekeeping, but still welcome discussion!

@Jack-Works Jack-Works closed this as not planned Won't fix, can't repro, duplicate, stale Mar 22, 2023
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

4 participants