Move from getters to configurable non-writable own properties?
Jack-Works opened this issue · comments
@jorendorff writes:
Getters are for querying internal state; if there's nothing "internal" about it, a data property seems more idiomatic to me.
The argument makes sense for range proposal. The API is designed to be immutable so it's not possible to change step, start, end. Since there is no internal state, it's better to use its own properties.
What if the developer re-configure the options?
-
Current spec: Will change the number emitted, but after moving to the build-in generator(tc39/ecma262#2045), the options will be carried in the abstract closures so it's not breaking.
-
Helper methods on the iterator prototype: Will be affected if they're rely on the options. This will also give up the brand check so a future helper method can work on non-range-iterator objects.
// slot+getter
range.includes(2) // impossible to change range.start/end
range.includes.call({start:0, end:5}) // throws
// own property
range.includes(2) // possible to re-configure start/end to change the result
range.includes.call({start: 0, end: 5}, 2) // okmaybe @erights interested in this (I do want to avoid any new internal slots)
I do not think .call is a usage pattern we'd want to recommend, nor one people would commonly use.
start/end/step are indeed internal state of the range, and thus should be stored in slots.
But those options are immutable, there is no plan to modify it either.
Right - they’re an intrinsic part of a given instance, hence, a slot.
We really need some guideline of accessor of internal slots VS. own data property.