Skip to content
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.

Sign up for GitHub

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: Permit serialization of BigInt #3480

Merged
merged 2 commits into from
Feb 26, 2018
Merged

Normative: Permit serialization of BigInt #3480

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3ca3a7e
Normative: Permit serialization of BigInt wrappers
littledan Feb 17, 2018
ff56f34
Fix editorial issues, mostly pre-existing
domenic Feb 26, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3082,6 +3082,8 @@ a.setAttribute('href', 'https://example.com/'); // change the content attribute
<li>The <dfn data-x="js-HostGetImportMetaProperties" data-x-href="https://tc39.github.io/proposal-import-meta/#sec-hostgetimportmetaproperties">HostGetImportMetaProperties</dfn> abstract operation</li>
</ul>

<p>Users agents that support JavaScript must also implement the <cite>BigInt</cite> proposal. <ref spec=JSBIGINT></p>

</dd>


Expand Down Expand Up @@ -8127,7 +8129,8 @@ interface <dfn>DOMStringList</dfn> {
<li><p>Let <var>deep</var> be false.</p></li>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the same order that the JavaScript specification will use?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find a list containing these three types in the JavaScript specification. The definition of == contains "String, Number, BigInt, or Symbol" but I didn't really give it any thought when I inserted BigInt in that position.

Should we have a total order of JS primitive types, and whenever we have a list, sort them by that order? What should be this total order? I'd like to defer these advanced editorial questions to the JS spec community's more experienced editorialists, e.g., @jmdyck

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about the order of the section 6.1 subsections.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Speaking of which, is the fact that we omit Symbol here a bug?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it seems we made a decision to throw on symbols. I'm not sure why, but they are quite different from other primitives, so maybe it makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A: Undefined, Null, Boolean, Number, String, Symbol, Object
B: Undefined, Null, Boolean, Number, Symbol, String
C: Undefined, Null, Boolean, String, Symbol, Number, Object
D: Undefined, Null, Boolean, Number, String, Symbol, Object
E: Undefined, Null, Boolean, Number, String, Symbol, Object
F: Undefined, Null, Boolean, Number, String, Symbol, Object
G: Undefined, Null, Boolean, Number, String, Symbol, Object
H: Undefined, Null, Boolean, Number, String, Symbol, Object
I: Undefined, Null, Boolean, String, Symbol, Number, Object
J: Undefined, Null, Boolean, Number, String, Symbol, Object

So a fair bit of consistency, but also some variation.

About the only benefit I can think of for a consistent order is that it makes it easier to check by eye that some list (set of cases) is complete. Mind you, this benefit would increase as more types are added to the language.

About the only disadvantage I can think of is that if you're doing a case analysis, it might make more sense to the reader to describe the handling of Type X before that for Type Y, and those orderings might not be consistent over the whole spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember from who, but I remember hearing some interest in extending structured clone to Symbols. My impression was that it was left out because it'd be somewhat complicated to make the proper global registry so that if you postMessage the symbol around multiple ways, you get the same one (e.g., sending S from A -> B -> C and also A -> C directly, you'd hope to get the same S').

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmdyck Where do you think BigInt should be inserted in the list?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjacent to Number, presumably, but I'm not sure about before or after.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's say BigInt goes after Number, unless someone has a preference otherwise.

<li><p>If <span data-x="js-Type">Type</span>(<var>value</var>) is Undefined, Null, Boolean,
String, or Number, then return { [[Type]]: "primitive", [[Value]]: <var>value</var> }.</p></li>
Number, BigInt, or String, then return { [[Type]]: "primitive",
[[Value]]: <var>value</var> }. <ref spec=JSBIGINT></p></li>

<li><p>If <span data-x="js-Type">Type</span>(<var>value</var>) is Symbol, then throw a
<span>"<code>DataCloneError</code>"</span> <code>DOMException</code>.</p></li>
Expand All @@ -8141,6 +8144,10 @@ interface <dfn>DOMStringList</dfn> {
<var>serialized</var> to { [[Type]]: "Number", [[NumberData]]: <var>value</var>.[[NumberData]]
}.</p></li>

<li><p>Otherwise, if <var>value</var> has a [[BigIntData]]
internal slot, then set <var>serialized</var> to { [[Type]]: "BigInt", [[BigIntData]]:
<var>value</var>.[[BigIntData]] }. <ref spec=JSBIGINT></p></li>

<li><p>Otherwise, if <var>value</var> has a [[StringData]] internal slot, then set
<var>serialized</var> to { [[Type]]: "String", [[StringData]]: <var>value</var>.[[StringData]]
}.</p></li>
Expand Down Expand Up @@ -8546,6 +8553,10 @@ o.myself = o;</pre>
<var>targetRealm</var> whose [[NumberData]] internal slot value is
<var>serialized</var>.[[NumberData]].</p></li>

<li><p>Otherwise, if <var>serialized</var>.[[Type]] is "BigInt", then set <var>value</var> to a new BigInt object in
<var>targetRealm</var> whose [[BigIntData]] internal slot value is
<var>serialized</var>.[[BigIntData]]. <ref spec=JSBIGINT></p></li>

<li><p>Otherwise, if <var>serialized</var>.[[Type]] is "String", then set <var>value</var> to a new String object in
<var>targetRealm</var> whose [[StringData]] internal slot value is
<var>serialized</var>.[[StringData]].</p></li>
Expand Down Expand Up @@ -120209,6 +120220,9 @@ INSERT INTERFACES HERE
<dt id="refsJPEG">[JPEG]</dt>
<dd><cite><a href="https://www.w3.org/Graphics/JPEG/jfif3.pdf">JPEG File Interchange Format</a></cite>, E. Hamilton.</dd>

<dt id="refsJSBIGINT">[JSBIGINT]</dt>
<dd><cite><a href="https://tc39.github.io/proposal-bigint/">BigInt</a></cite>. Ecma International.</dd>

<dt id="refsJSIMPORT">[JSIMPORT]</dt>
<dd><cite><a href="https://tc39.github.io/proposal-dynamic-import/">import()</a></cite>. Ecma International.</dd>

Expand Down