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

Possible name of renaming #45

Closed
Jack-Works opened this issue Feb 25, 2021 · 9 comments
Closed

Possible name of renaming #45

Jack-Works opened this issue Feb 25, 2021 · 9 comments

Comments

@Jack-Works
Copy link
Member

Jack-Works commented Feb 25, 2021

So per discussion in #42 I think most people do not comfortable with class. I'm not OK to ship Number.range without hinting it is an iterator in the name so I'm going to rename this proposal.

Requirements:

  1. Must hint to the developers it is an iterator.

Example:

  • Number.rangeIterator or Iterator.numericRange (unify all kinds of numbers, bigints, ...etc) or Iterator.numberIterator+Iterator.bigintIterator.
  • 🚫 Number.range
  1. Must have "number", "bigint" or "numeric" in the name.

To avoid the embarrassment if we want to add things like String ranges, Temporal ranges (maybe we do have it?), or other kinds of ranges, the name must include number, bigint or numeric (if merge number and bigint into one API).

  • Iterator.numericRange
  • 🚫 Iterator.range

=======================================

Though I strongly want to hint at both "iterator", "range", and "number" in the API name, I'm worrying if it will hurt the egenomics because the name is too long. Maybe it is not a problem because all modern IDEs and debuggers will provide completion for the API so it is not a problem? I don't know.

@zloirock
Copy link
Contributor

Please, no. It's like moving Array#keys to Iterator.arrayIndexNumberIterator.

@Jack-Works
Copy link
Member Author

Please, no. It's like moving Array#keys to Iterator.arrayIndexNumberIterator.

Interesting point, let me consider this

@ljharb
Copy link
Member

ljharb commented Feb 25, 2021

Why would it need "iterator" in the name? keys/values/entries/matchAll are all functions in the language that provide an iterator, and nobody's seemed confused by those.

@Jack-Works
Copy link
Member Author

Why would it need "iterator" in the name? keys/values/entries/matchAll are all functions in the language that provide an iterator, and nobody's seemed confused by those.

So I have heard a point (maybe from @hax) that most of the built-in methods that return an iterator are not configurable via option bags. But this one is different. (Oh so matchAll is the same case as range)

@ljharb
Copy link
Member

ljharb commented Feb 25, 2021

I also don't know why an options bag would make a difference, unless you're suggesting that an option would be able to change the return type of the function, which I'd find very confusing and problematic.

@Jack-Works
Copy link
Member Author

Another difference is keys/values/entries/matchAll are prototype methods and range is not. 🤔

@ljharb
Copy link
Member

ljharb commented Feb 25, 2021

Why would the placement of a method create confusion about the return type? Reflect.enumerate, before it was removed (due to not being a proxy trap), was a static method that returned an iterator.

@Jack-Works
Copy link
Member Author

Hmm, that makes sense to me. I need to consider more about this. Let me close this for now.

Another question. Are people here (and in #42) are good with the status quo?

@devsnek
Copy link
Member

devsnek commented Feb 25, 2021

I don't think any modern languages put the types in method names 😬

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