Skip to content

[[Calendar]] in Temporal.PlainTime and GetISO8601Calendar() #1588

@FrankYFTang

Description

@FrankYFTang

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    normativeWould be a normative change to the proposalspec-textSpecification text involved

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions