Closed Jack-Works closed 6 months ago
This seems like a good follow-on proposal, and a good argument for making it an options bag, but seems a bit beyond the scope of the initial proposal?
since the basic API shape is decided, adding useful options isn't out of the scope, but we can also leave it for the future.
True, but what are the problems being solved by sampling? I don't see any that were provided through the stage 1 or 2 advancements. New problems to solve suggests to me that a new proposal is appropriate.
@Jack-Works I would disagree. The committee didn't approve an API space where you can throw in any features you want. The committee approved a specific solution to specific problems. Any increase in scope should be brought back to committee, even if it would have a minor change in the API.
@Jack-Works why don't you use an object parameter as follows:
Iterator.range = function(obj) { /* obj.start, obj.end, obj.step, obj['<someOtherPropertyConsideredLater>'] */ }
This approach allows for arbitrary placement of the arguments passed to
Iterator.range
as well as backwards-compatible implementations in the form of new parameters
Typically, options objects are used for optional parameters, not required ones.
@Jack-Works why don't you use an object parameter as follows:
Iterator.range = function(obj) { /* obj.start, obj.end, obj.step, obj['<someOtherPropertyConsideredLater>'] */ }
This approach allows for arbitrary placement of the arguments passed to
Iterator.range
as well as backwards-compatible implementations in the form of new parameters
I want to optimize for the most common use cases, which definitely have a start and end parameter.
It's also possible to do the thing you suggested when arguments length is 1, but I don't find a use case for now. (We can add it in the future if there is one).
Perhaps you did not understand my comment @Jack-Works Here is what I meant
Iterator.range = function(obj) {
/* obj.start, obj.end, obj.step, obj['<someOtherPropertyConsideredLater>'] */
if(obj.start&&ob.end) {
//will be false for ob.start or obj.end = 0, implement correctly, just a suggestion
}
}
Pros
This approach will make the arbitrary and flexible placement of arguments passed to Iterator.range
possible.
A change in the spec down the line will involve breaking changes that may be solved by this approach.
You need not even rely on overloading the function or on arguments.length === 1
Cons
Iterator.range
is an object and not a numberNo, they understood it. Jack and Jordan both explained why that's not an API shape we're going for - we don't usually put required arguments (like the start or end) into option bags, and specifying both start and end is very common. If you do want to just iterate from 0 to some limit, saying so is extremely simple, so we judged it's not worth the cost of adding a signature overload specifically for that case.
we don't usually put required arguments (like the start or end) into option bags
I agree.
@ogbotemi-2000 {start, end}
looks more like a "range-like" object, if we chose reusable iterable api, we might explore such API shape (NumberRange.from({start, end})
), but it's not very fit current proposal.
I'll close this issue for now for housekeeping. At today's TC39 meeting, delegates are generally satisfied with the status quo API. It's still possible to add this feature but we need to find the new motivation for this.
originally proposed by @hax in https://github.com/tc39/proposal-Number.range/issues/25
it will sample 3 numbers in the range of 10n to 20n. without sampling, it would become