-
Notifications
You must be signed in to change notification settings - Fork 16
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
Incomplete amount of exposed state on %SegmentIteratorPrototype% #54
Comments
Could you say why (beyond that it's "strange")? I'd like to make that iterator return objects that are not invalidated by future |
Well, none of the ECMAScript built-in iterators expose any state at all beyond a What makes this API so special that it demands auto-memoization of |
One reason is that we need preceding and following methods, see #9 . Another is performance concerns (I am having trouble finding that thread). Please, you can disagree, but don't assume that all of this is just in place by accident. |
I don't dispute that arbitrary-index As for performance, I don't want to get into that guessing game but will observe that if bypassing object allocations were a strong concern (which I'd argue against anyway), then all the result properties should be mirrored as accessors on the iterator, rather than just two of them (in particular, |
If you want to avoid these kinds of impressions, you could start by asking why, rather than filing a bug claiming incorrectness. Segment is just a convenience property, which you can calculate based on the string, the position before, and the position after. It is omitted to avoid that allocation. PRs welcome to improve the documentation to summarize the result of #9. |
Updated to replace "incorrect" with the more accurate "incomplete". But I try not to phrase issues as questions because the resolution shouldn't be an answer, it should be either an update to the explainer or an update to the spec text—and it's impossible to determine which without an issue to capture discussion. I'm happy to adapt to whatever patterns you prefer, though... where would you like to see such questions?
You keep asking me to submit PRs explaining decisions, but I can't do that for decisions that didn't come with reasons. #9 requested
The iterator object has internal slots for position and break type, and everything else is derived from those—the iteration result currently has explicit I'll open some PRs to clarify what I'm talking about. |
I'm not trying to put the burden on you to make PRs, though I'd really appreciate your help. If no one gets around to it, I hope to eventually come back and do it. I don't actually understand what's incomplete about #9, or what kind of thing would make them "pay for themselves". What makes them expensive? About |
Nothing. This issue is totally unrelated to #9. It is about duplicating information from iteration results on the iterator itself—specifically,
They are expensive in terms of the cognitive burden and spec complexity of Intl segment iterators being different from ES string iterators and every other built-in iterator, none of which directly expose state.
That sounds like premature optimization, which someone once called "the root of all evil (or at least most of it) in programming". The benefit of avoiding object allocations comes at the cost of introducing significant internal inconsistency in the form of properties that have no analogues on otherwise similar iterators and—in the case of Couldn't we at least try the simple conventional interface first? If this complexity is actually worthwhile, then perhaps it should be added across the board rather than limited to a single built-in iterator. |
Cc @sebmarkbage who raised the performance issue IIRC |
I removed |
It's a bit strange for each segmentIterator to expose some but not all of the data returned by its
next
method. I'd be in favor of droppingbreakType
, or—if keeping it serves some important purpose—replacing both it andposition
/index
with an accessor that echoes the most recent object fromnext
.The text was updated successfully, but these errors were encountered: