Spec Text Size Reductions: Tracking Ticket

[arshaw]

This ticket tracks progress for all other tickets meant to reduce the number of calls to user code repeated sections of the spec text. These are/will be implemented as merely PROOFS OF CONCEPT at first. The original goal of this was to improve runtime performance and reduce user code calls. Now the goal is to make the code more DRY for decreased proposal size and file size of compiled code in implementations.

• Fewer CalendarDateAdd/DateUntil calls during relative rounding #2792 (test262 diff)
  • Blocked on Normative: Fix Duration rounding relative to ZonedDateTime #2758
  • Size reduction: HIGH
• Fewer CalendarDateAdd/DateUntil calls during day-rounding w/ PlainDate #2791 (test262 diff)
  • Blocked on Fewer CalendarDateAdd/DateUntil calls during relative rounding #2792
  • Size reduction: NONE
• Editorial: Fewer GetOffsetNanosecondsFor calls during InterpretISODateTimeOffset (prefer/reject) #2789
  • Size reduction: NONE
• Fewer CalendarDay/CalendarDateFromFields calls during PlainYearMonth add/subtract #2798
  • Size reduction: LOW

Bugs

Tickets that BOTH require bugfixing AND will decrease # of user calls and reduce filesize when fixed:

• Normative: Fix ZonedDateTime::round incorrect results with smallestUnit:day #2797
  • Size reduction: LOW
• Normative: [Alt PR] Fix intermediate value in ZonedDateTime difference #2810 (test262 diff)
  • Size reduction: NONE
• Normative: Fix Duration rounding relative to ZonedDateTime #2758 (need test262 diff)
  • Size reduction: MEDIUM

Other DRY-ness

In addition to above, there are other ways to make the code more DRY:

• Unify code paths for YMD diffing:
  • Size reduction: MEDIUM
  • reference polyfill (ISO: DifferenceISODate, Intl: nonIsoHelperBase.untilCalendar) VS fullcalendar polyfill (combined: diffYearMonthDay)
• Options parsing for diffing rounding (roundingIncrement, roundingMode)
  • maximumIncrements/MAX_DIFFERENCE_INCREMENTS

[ptomato]

As of #2826, we are getting rid of user code calls, so let's change the focus of this to just DRY the spec algorithms. Once #2826 happens, these should all be editorial changes, so they are less urgent; we should get them incorporated before declaring the spec stable though.

[ptomato]

@arshaw Most of the items from this list are now done. It's just the two remaining ones under "Other DRY-ness" left.

"Unify code paths for YMD diffing" would currently not actually result in a spec text size reduction, because the calendar-dependent CalendarDateDifference is left as implementation-defined. Shrinking the size of the reference polyfill is quite low priority, since it's not used in production. So I'm inclined to just cross this one off the list.

(Note, there is an issue open to specify CalendarDateDifference in the Intl Era and Month Codes proposal. We could revisit this in the future, if it becomes feasible to specify DifferenceISODate in terms of CalendarDateDifference.)

"Options parsing for diffing rounding (roundingIncrement, roundingMode)" I'm not sure what to do with this one, but it sounds like you had a refactor in mind. Would you like to open a ticket for that with more details, and close this one?

[arshaw]

That's great news @ptomato. Looking at how to DRY-up roundingIncrement parsing (GetRoundingIncrementOption, MAX_DIFFERENCE_INCREMENTS , ValidateTemporalRoundingIncrement and the like), I'm realizing the DRY-ness works well in a JS polyfill but would be challenging to do in a statically typed language, so I rescind this!