-
Notifications
You must be signed in to change notification settings - Fork 157
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
Editorial: Simplify object snapshotting #2586
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2586 +/- ##
=========================================
+ Coverage 0 96.14% +96.14%
=========================================
Files 0 20 +20
Lines 0 11364 +11364
Branches 0 2164 +2164
=========================================
+ Hits 0 10926 +10926
- Misses 0 375 +375
- Partials 0 63 +63
|
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.
Looks like a good improvement!
Would you like to propose the change to rest parameter destructuring in 262 separately? That would help make the Temporal proposal a bit smaller and get some editor feedback on this operation.
Good idea: tc39/ecma262#3081 |
@@ -1505,12 +1505,8 @@ <h1>Temporal.Calendar.prototype.mergeFields ( _fields_, _additionalFields_ )</h1 | |||
<emu-alg> | |||
1. Let _calendar_ be the *this* value. | |||
1. Perform ? RequireInternalSlot(_calendar_, [[InitializedTemporalCalendar]]). | |||
1. Set _fields_ to ? ToObject(_fields_). |
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.
Why is it ToObject
and not "If fields is not an Object, throw a TypeError" ?
And was it an accidentally normative change to remove it here?
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.
To answer the second question first, this change is not normative because the first observable consequence of SnapshotOwnProperties is ? ToObject(_source_)
in step 3.
As for the first question, I don't know why mergeFields
includes coercion to object but I would be in favor of replacing that with rejection of non-objects in concordance with #2574 (and such a change could be implemented in SnapshotOwnProperties itself).
…ewers,dminor Per <tc39/proposal-temporal#2586>. Differential Revision: https://phabricator.services.mozilla.com/D182055
…ewers,dminor Per <tc39/proposal-temporal#2586>. Differential Revision: https://phabricator.services.mozilla.com/D182055
…ewers,dminor Per <tc39/proposal-temporal#2586>. Differential Revision: https://phabricator.services.mozilla.com/D182055 UltraBlame original commit: 1a2a324c251824b802d2f635171b5223022dc671
…ewers,dminor Per <tc39/proposal-temporal#2586>. Differential Revision: https://phabricator.services.mozilla.com/D182055 UltraBlame original commit: 1a2a324c251824b802d2f635171b5223022dc671
…ewers,dminor Per <tc39/proposal-temporal#2586>. Differential Revision: https://phabricator.services.mozilla.com/D182055 UltraBlame original commit: 1a2a324c251824b802d2f635171b5223022dc671
Introduces SnapshotOwnProperties to precede CopyDataProperties with creating the target object and follow it with returning that object, collapsing many common algorithm subsequences (including all of those using the CopyOptions operation, which is fully subsumed).
Once introduced to ECMA-262, it can also simplify RestDestructuringAssignmentEvaluation and RestBindingInitialization: