-
Notifications
You must be signed in to change notification settings - Fork 149
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
Normative: Validate receiver fields before fields of any param objects #2478
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -227,11 +227,11 @@ <h1>Temporal.PlainYearMonth.prototype.with ( _temporalYearMonthLike_ [ , _option | |
1. If Type(_temporalYearMonthLike_) is not Object, then | ||
1. Throw a *TypeError* exception. | ||
1. Perform ? RejectObjectWithCalendarOrTimeZone(_temporalYearMonthLike_). | ||
1. Set _options_ to ? GetOptionsObject(_options_). | ||
1. Let _calendar_ be _yearMonth_.[[Calendar]]. | ||
1. Let _fieldNames_ be ? CalendarFields(_calendar_, « *"month"*, *"monthCode"*, *"year"* »). | ||
1. Let _partialYearMonth_ be ? PrepareTemporalFields(_temporalYearMonthLike_, _fieldNames_, ~partial~). | ||
1. Set _options_ to ? GetOptionsObject(_options_). | ||
1. Let _fields_ be ? PrepareTemporalFields(_yearMonth_, _fieldNames_, «»). | ||
1. Let _partialYearMonth_ be ? PrepareTemporalFields(_temporalYearMonthLike_, _fieldNames_, ~partial~). | ||
1. Set _fields_ to ? CalendarMergeFields(_calendar_, _fields_, _partialYearMonth_). | ||
1. Set _fields_ to ? PrepareTemporalFields(_fields_, _fieldNames_, «»). | ||
1. Return ? CalendarYearMonthFromFields(_calendar_, _fields_, _options_). | ||
|
@@ -611,12 +611,12 @@ <h1> | |
1. If ? CalendarEquals(_calendar_, _other_.[[Calendar]]) is *false*, throw a *RangeError* exception. | ||
1. Let _settings_ be ? GetDifferenceSettings(_operation_, _options_, ~date~, « *"week"*, *"day"* », *"month"*, *"year"*). | ||
1. Let _fieldNames_ be ? CalendarFields(_calendar_, « *"monthCode"*, *"year"* »). | ||
1. Let _otherFields_ be ? PrepareTemporalFields(_other_, _fieldNames_, «»). | ||
1. Perform ! CreateDataPropertyOrThrow(_otherFields_, *"day"*, *1*<sub>𝔽</sub>). | ||
1. Let _otherDate_ be ? CalendarDateFromFields(_calendar_, _otherFields_). | ||
1. Let _thisFields_ be ? PrepareTemporalFields(_yearMonth_, _fieldNames_, «»). | ||
1. Perform ! CreateDataPropertyOrThrow(_thisFields_, *"day"*, *1*<sub>𝔽</sub>). | ||
1. Let _thisDate_ be ? CalendarDateFromFields(_calendar_, _thisFields_). | ||
1. Let _otherFields_ be ? PrepareTemporalFields(_other_, _fieldNames_, «»). | ||
1. Perform ! CreateDataPropertyOrThrow(_otherFields_, *"day"*, *1*<sub>𝔽</sub>). | ||
1. Let _otherDate_ be ? CalendarDateFromFields(_calendar_, _otherFields_). | ||
1. Let _untilOptions_ be OrdinaryObjectCreate(*null*). | ||
1. Perform ? CopyDataProperties(_untilOptions_, _settings_.[[Options]], « »). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is curious that this step can throw; is that a bug in failure to properly consume options earlier on? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think it's a bug - we have to perform CopyDataProperties on options at some point, so that we can pass an options object to CalendarDateUntil with a modified There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, I'm saying that the bug is consuming it so deep in the spec algorithms rather than in initial processing—and in particular in performing CopyDataProperties after GetDifferenceSettings has read several properties on its own. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could see this going either way - it'd be good to eliminate the duplicate reads, but on the other hand we'd introduce an inconsistency where we'd copy the options object in the since/until methods of PlainDate, PlainDateTime, PlainYearMonth, and ZonedDateTime; and not copy it in the since/until methods of PlainTime and Instant. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wouldn't options be copied in all since/until methods? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Only the ones where a modified options object needs to be passed on to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, either that serves as explanation of the inconsistency or we'd copy options in all since/until methods even though some technically don't need it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you have a concrete proposal for this? If we can manage to write that additional change before TC39's review deadline, I wouldn't be opposed to including it here. Otherwise I think it can be done as part of #2289 or left as is. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Concretely, I'm proposing I agree that it is logically part of the fixes for #2289, but will still try to put up a narrow PR since it has been specifically identified (and in fact already has a comment: #2289 (comment) ). |
||
1. Perform ! CreateDataPropertyOrThrow(_untilOptions_, *"largestUnit"*, _settings_.[[LargestUnit]]). | ||
|
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.
It's debatable whether we'd want to make this change to PlainTime, which doesn't use PrepareTemporalFields, but it seems most consistent with the form suggested by Richard in #2462 (comment)
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.
👍
But if this is awkward and options never affects the interpretation of the first argument, then it would also be coherent to move every
Set _options_ to ? GetOptionsObject(_options_).
to follow full consumption (with constituent validation) of the first argument by PrepareTemporalFields/ToTemporalTimeRecord/etc.—although that is not my preference because it's not clear to me in that case whether GetOptionsObject should precede or follow integration of receiver and argument data in e.g. CalendarMergeFields.