-
Notifications
You must be signed in to change notification settings - Fork 172
Description
Currently, in Temporal.PlainTime Instances
https://tc39.es/proposal-temporal/#sec-properties-of-temporal-plaintime-instances
[[Calendar]] | An instance of the built-in ISO 8601 calendar.
and
https://tc39.es/proposal-temporal/#sec-temporal-createtemporaltime
11. Set object.[[Calendar]] to ? GetISO8601Calendar().
So... what is the value for the Temporal.PlainTime carry this internal slot if the slot is always getting the same kind of calendar (but different object) and the calendar internally carry no state information. It force the implementation to use more memory than it needed to and provide no value.
from what I can I read the spec mandate us to make sure the following
let a = new Temporal.PlainTime(....)
let b = new Temporal.PlainTime(....)
# different Temporal.PlainTime must return different object of Temporal.Calendar)
# so my implementation can NOT cache one Temporal.Calendar object per identifier and re use it
# for all reference to that "iso8601" calendar.
a.calendar == b.calendar => must be false
# different calls to the get Temporal.PlainTime.prototype.calendar must return the same Temporal.Calendar object
# so my internal implementation can NOT choose not to create the calendar in the constructor but only create one
# in the get Temporal.PlainTime.prototype.calendar
a.calendar == a.calendar => must be true
Please forgive me if I misunderstand the interpretation of the spec. I try to figour out how to optimize the memory usage for PlainTime. My first intutiion is that since the calendar is always iso8601 there are no need to create on and store it into the internal slot and we could skip a pointer in the PlainTime internal storage and always call GetISO8601Calendar() to return a new copy in the getter of calendar.