-
Notifications
You must be signed in to change notification settings - Fork 154
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: Rename "normalize" and "unnormalize" for durations #3007
Conversation
Here are a couple of stragglers from PR #2943.
Another couple of leftovers from PR #2943.
"Normalized" was jargon that we adopted after the February 2023 TC39 meeting. "Internal" is clearer; we convert a Temporal.Duration into an "internal" record for calculations. See: #2953
This operation used to do more than just calculate the number of days, and the name used to make more sense when we had BalanceRelative, etc. Now it's just confusing. Rename it to reflect what it does. See: #2953
A normalized time duration is just a number of nanoseconds; we originally planned to convert it to a record with a seconds and subseconds field, but that was never needed. So we don't need to have it be a record in the first place. Rename it to "time duration" (removing "normalized" for the same reason as in the previous commits) and define it as an integer within a certain range. Renames: - all of the NormalizedTimeDuration___ operations to just TimeDuration___ - NormalizeTimeDuration to TimeDurationFromComponents - Internal duration [[NormalizedTime]] field to [[Time]] - "norm" variables to "timeDuration" or "time" if clear from context See: #2953
We originally planned to convert time durations to a record with a seconds and subseconds field, but that was never necessary. Now that they are just a mathematical value, we don't need to access them through these seconds and subseconds operations. See: #2953
This previously needed to be a separate operation because you can't just negate a record. Now that time durations are a number, you can negate them, so no need for a subtraction operation when we already have an addition operation.
It now just returns 0. No need to have an operation for that. See: #2953
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3007 +/- ##
=======================================
Coverage 95.89% 95.89%
=======================================
Files 21 21
Lines 9678 9681 +3
Branches 1837 1837
=======================================
+ Hits 9281 9284 +3
Misses 344 344
Partials 53 53 ☔ View full report in Codecov by Sentry. |
CompareNormalizedTimeDuration ( | ||
_one_: a Normalized Time Duration Record, | ||
_two_: a Normalized Time Duration Record, | ||
CompareTimeDuration ( |
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.
I considered inlining AOs like this one, but I think implementations will probably represent time durations as a struct, not a single number. Personally, I'd do it as a 64-bit number of seconds and 32-bit number of subseconds. Given that, I think it still makes sense for operations like these to be considered "methods" of time durations.
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.
👍
Thanks for the quick review, glad we could get all this landed before the plenary presentation. |
Rename for reasons described in #2953, and change Normalized Time Duration Record to be an integer within a particular range, which allows simplifying several abstract operations as discussed there.
Closes: #2953