GetOptionsObject vs OrdinaryObjectCreate(%Object.prototype%)

[Ms2ger]

NormalizeOptionsObject is used in some places when an options argument is needed, which creates a new object inheriting from null instead of Object.prototype. A bunch of other places instead do OrdinaryObjectCreate(%Object.prototype%). It seems like these should be consistent, and (as a non-editorial opinion) NormalizeOptionsObject seems better: I wouldn't expect omitting an options argument to cause lookups on Object.prototype.

Some earlier discussion in #1424

[ptomato]

I thought this was fixed already; are there any places left where an options object created within Temporal does not have a null prototype?

[linusg]

Note that NormalizeOptionsObject is now called GetOptionsObject (see a7458d3); you might want to update the issue title & description.

[Ms2ger]

I found:

• Temporal.PlainYearMonth.prototype.add/subtract
• DefaultMergeFields / Temporal.Calendar.prototype.mergeFields
• MergeLargestUnitOption
• PrepareTemporalFields
• PreparePartialTemporalFields

Plus getISOFields, DateTimeFormat, and the Temporal objects themselves, but those seem fine.

[ptomato]

I agree PlainYearMonth.add/subtract and MergeLargestUnitOption should be fixed.

mergeFields/DefaultMergeFields and PrepareTemporalFields/PreparePartialTemporalFields I didn't consider before because they weren't options objects. But maybe it makes sense to make these into null prototype objects too. For objects returned from PrepareTemporalFields it really shouldn't matter because we only Get properties that are guaranteed to be own data properties of the object. But for PreparePartialTemporalFields, you could write some evil code where it is observable:

Temporal.PlainDate.from('2022-01-01').with({
  get year() {
    Object.prototype.day = 31;
    return 2023;
  },
});

You'd expect this to result in 2021-01-01 but it might result in 2021-01-31...

[Ms2ger]

I'd say:

• Let's change PlainYearMonth.add/subtract
• I think mergeFields is fine with Object.prototype since it just returns the object back to the caller
• Change MergeLargestUnitOption
• Seems like PrepareTemporalFields doesn't matter
• Change PreparePartialTemporalFields as well

[ptomato]

Sounds like we agree. If PrepareTemporalFields doesn't matter, then probably we should still change it for consistency with PreparePartialTemporalFields, since consistency is the reason the issue was opened in the first place.