-
Notifications
You must be signed in to change notification settings - Fork 106
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: GetOption reform #493
Conversation
spec/datetimeformat.html
Outdated
1. Else, | ||
1. If Type(_options_) is not Object, | ||
1. Throw a *TypeError* exception. | ||
1. Let _options_ be ObjectCreate(_options_). |
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.
i'm kind of confused why ObjectCreate is/was used here - does the spec mutate the options object?
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.
I was trying to preserve the previous behaviour, so I don't know the answer to this; maybe because the subsequent Gets would otherwise be observable?
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.
ToDateTimeOptions does indeed perform some writes, and the consequences are unnecessarily weird.
let observing = true;
const wrappers = new Set();
const options = new Proxy({}, {
get(target, prop, receiver){
if(observing) console.log("get:", prop, (
receiver === options ?
"@options" :
Object.getPrototypeOf(receiver) === options ?
"@wrapper" + [...wrappers.add(receiver)].indexOf(receiver) :
receiver
));
let val = target[prop];
Reflect.defineProperty(target, prop, {
enumerable: true,
get(){ return val },
set(v){
if (observing) console.log("set:", prop, v, (
this === options ?
"@options" :
Object.getPrototypeOf(this) === options ?
"@wrapper" + [...wrappers.add(this)].indexOf(this) :
this
));
val = v;
return true;
}
});
return val;
}
});
new Intl.DateTimeFormat(undefined, options);
/* =>
get: weekday @wrapper0
get: year @wrapper0
get: month @wrapper0
get: day @wrapper0
get: hour @wrapper0
get: minute @wrapper0
get: second @wrapper0
get: fractionalSecondDigits @wrapper0
get: localeMatcher @wrapper0
get: calendar @wrapper0
get: numberingSystem @wrapper0
get: hour12 @wrapper0
get: hourCycle @wrapper0
get: timeZone @wrapper0
get: dateStyle @wrapper0
get: timeStyle @wrapper0
get: weekday @wrapper0
get: era @wrapper0
get: hour @wrapper0
get: minute @wrapper0
get: second @wrapper0
get: timeZoneName @wrapper0
get: fractionalSecondDigits @wrapper0
get: formatMatcher @wrapper0
*/
observing = false;
[...wrappers].forEach((wrapper, i) => {
console.log("wrapper" + i + ":", wrapper, Object.getPrototypeOf(wrapper));
});
// => wrapper0: {year: "numeric", month: "numeric", day: "numeric"} Proxy {…}
If we're making normative changes, I'd like to remove observable internal objects and multiple reads of the same properties.
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.
In that case, shouldn’t the object be cloned before it’s written to, instead of making an inheriting object? (something that’s observable via proxies, and a very weird thing imo to have be observable)
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.
Long-overdue issue: #706
I understand the goal for consistency, but I'm slightly concern about the potential breaking changes. If a normative change is proposed where we limit a feature we've had before, I'd like to see Test262 reflecting these in details because we need to understand the possible outcomes for a potential breaking change. With these tests I can also ask implementers if they are good with the proposed change. Probably the easiest outcome would be a different abstract for Temporal. |
87ef9e8
to
235c0d2
Compare
I've updated this with the suggestions in #480. It now does not change any observable behaviour. If desired, subsequent normative changes could be made:
(Edit 2021-01-08: renamed abstract operations) |
spec/negotiation.html
Outdated
@@ -304,6 +301,36 @@ <h1>SupportedLocales ( _availableLocales_, _requestedLocales_, _options_ )</h1> | |||
</emu-alg> | |||
</emu-clause> | |||
|
|||
<emu-clause id="sec-normalizeoptionsobject" aoid="NormalizeOptionsObject"> | |||
<h1>NormalizeOptionsObject ( _options_ )</h1> |
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.
Only in 262, right?
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.
I put it in here initially as per #480 (comment)
733f057
to
e19b070
Compare
4dc3db3
to
55fae46
Compare
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.
The changes look good, but I think some naming and descriptions could be a little better.
I'm in agreement with @gibson042's suggestions. @ptomato please let me know if you're interesting in updating this. As those are minor edits, I can do it from here before merging. Thanks! |
Thanks for the reviews. I didn't get to update this before my vacation but I intend to do it sometime this week or next, if that timeline works for you. |
No problem, my goal is to have those things done by January to get a good cut for the 2021 Edition. |
In order to later be able to move GetOption into ECMA-262 in sync with Temporal, we add GetOptionsObject and CoerceOptionsToObject as abstract operations. GetOptionsObject and GetOption are intended to be moved into ECMA-262 at the same time, while CoerceOptionsToObject is intended to stay in ECMA-402. CoerceOptionsToObject describes the somewhat unexpected boxing behaviour when passing a primitive as the options parameter in a formatter constructor. This behaviour may need to be preserved for web-compatibility reasons, but new Intl objects going forward should use the GetOptionsObject behaviour.
Co-Authored-By: Ms2ger <[email protected]>
55fae46
to
31d433b
Compare
Updated. |
Discussion: #480