Just Number instead
ByteEater-pl opened this issue · comments
Number.range is still quite long. How about adding overloads with 2 and 3 parameters to the Number function?
There's still the case of 1 argument to consider which it would be desirable to treat as the second with the first assumed as 0. That should behave in a way similar to how it does currently, yet have a Symbol.iterator property bolted on. Would suitable valueOf, toString and a special case for typeof be sufficient for backward compatibility?
How about adding overloads with 2 and 3 parameters to the Number function?
I don't think that is a good idea. See the Array constructor, it can also create an Array with length 5 by Array(5) but also behave differently with Array(5, 6).
This has been caused confusing. We should not make this mistake again.
Number.range is still quite long.
In some other language, range is in the global scope, but in JS we should not do this because there are too many items in the globalThis. So just like we make isNaN -> Number.isNaN, there is no range but Number.range in the first time.
Yet there is another option that we can add a new syntax for the range. For example, Kotlin has x..y as a range from x to y. But with this syntax, it will be hard to set a step. I don't know how they resolve this.
On the gramma way, 1..toString will confuse with (1).toString and Number.range(1, toString) where toString is a variable name. If we choose x...y, this may also conflict with rest properties syntax (though they may not appear in the same context just like ({ if: 1}) is valid).
But with this syntax, it will be hard to set a step. I don't know how they resolve this.
Kotlin use x..y step s, step is just a infix method, so basically it's (x..y).step(s).
Instead of x...y syntax, we could just introduce Number.prototype.rangeTo() so u can write (1).rangeTo(3). It could also be userland if we have bind operator / extensions. 1::rangeTo(3).