Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Editorial: Refactor common alg of since/until into AOs #2167
Editorial: Refactor common alg of since/until into AOs #2167
Changes from 6 commits
272a605
406c8cc
90b909e
e975600
b226cd6
8899b07
3923021
4b9f615
e18ce02
802b1b9
07fb858
df6387c
885a76e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency, can we use the same logic for until vs. since handling that's used in all other AOs (especially
DifferenceTemporalPlainTime
whose behavior should be almost identical to this one except for overflow handling) ?Specifically, removing this swapping of
_other_
and_instant_
and then using logic like we use elsewhere. Like this:then...
and finally:
If there's a perf or other reason that this AO should use the swapping logic, then why doesn't
DifferenceTemporalPlainTime
have the same optimization?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What you are asking is not a refactoring of the current logic, but rather a different math. I am not opposing to do that but I lack of confidence to that kind of change. Just look at the current spec:
https://tc39.es/proposal-temporal/#sec-temporal.instant.prototype.since
https://tc39.es/proposal-temporal/#sec-temporal.instant.prototype.round
I simply copy the alg there and factor out. What you suggest is way more complicated than that and I do not feel I have the time to ensure such change is correct.
I am also trubled by the "consistency" ideology. "consistency" will need to end somewhere while the two different type are differeent. It is not avoidable some "consistency" will be broken to deal with type specific issue. WHER the "consistency" should end is the question and I feel we push too deep on this. I think "consistency" should be kept on public API level and someone want it to be in the AO function level. But inside alg of AO? I think that simply go too far.
How about we first land this AO with if/swap . And if you or anyone feel comfortable of changing that logic w/o introduce error (which I do not feel confident) than you can do that later in a separate editorial PR.