-
Notifications
You must be signed in to change notification settings - Fork 59
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
Refer to relevant realm instead of relevant global object #347
Conversation
79eca43
to
3aeca4e
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.
"this" is defined in Web IDL.
spec/Overview.html
Outdated
@@ -2062,9 +2061,6 @@ <h4>The deriveBits method</h4> | |||
<li> | |||
<p> | |||
Let |result| be a new {{ArrayBuffer}} |
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.
@bathos suggested referencing create here and elsewhere, 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.
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.
Yes, afaict “a new ArrayBuffer” isn’t actually defined at this level, right? Something needs to hit AllocateArrayBuffer somewhere to actually create a new ArrayBuffer object in the sense that new ArrayBuffer()
in ES code would, and Web IDL’s create an ArrayBuffer alg takes care of that.
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.
OK, fair enough. I've updated the text 👍
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 didn’t see the first reply about fetch & XHR here till now. The XHR one is definitely wrong because it links “new” to create a new object implementing the interface, and ArrayBuffer is not an interface. The fetch one doesn’t link it to anything and seems like it’s also a spec hiccup (though again, I’m not an editor/expert so YMMV w/ my analysis).
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 think for both of those specifications the text predates the IDL algorithm. Please file issues/PRs?
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.
Also, link out to WebIDL's `this` definition instead of referencing it explicitly. And finally, note that objects are created in the relevant realm of `this` by default, rather than mentioning it everywhere.
3aeca4e
to
e0c3afc
Compare
Er, right. I got misled by all of the instances of " |
@@ -1328,8 +1328,7 @@ <h3>Data Types</h3> | |||
<h3>Methods and Parameters</h3> | |||
<p> | |||
Unless otherwise stated, objects created by the methods defined in this section shall be associated with the | |||
[= relevant global object =] | |||
of `this` [[HTML]]. | |||
[= relevant realm =] of [= this =]. |
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.
This is interesting — is an “ambient” realm argument like this typical @annevk?
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.
Not really, though there is an issue against IDL to make realm available as ambient information in a way that matches this as folks get it wrong all the time.
associated with the | ||
[= relevant global object =] | ||
of `this` [[HTML]], and | ||
Let |result| be the result of [= ArrayBuffer/create | creating =] an {{ArrayBuffer}} | ||
containing the result of performing the derive bits operation |
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 would have imagined the “containing” part to be written as “with” as the byte sequence is an argument for the create algorithm (along with the realm argument, though iiuc that’s being treated as an implicit here). However I’m not an expert on this and couldn’t say for sure whether this phrasing already fits expectations.
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.
This specific algorithm is worded using "from", and that's the phrasing WebIDL itself seems to use in https://webidl.spec.whatwg.org/#arraybufferview-create, for example. I thought the existing "containing" sounded clearer, but I can change it if needed.
spec/Overview.html
Outdated
Let |result| be a new empty {{ArrayBuffer}} associated with the | ||
[= relevant global object =] | ||
of `this` [[HTML]]. | ||
Let |result| be a new empty {{ArrayBuffer}}. |
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.
This one seems wrong because this creates a non-growable ArrayBuffer whose length is 0, but the steps which follow “append bytes” to it. Presumably the intent is to append to result.[[ArrayBufferData]]
, but even so, that isn’t possible — that Data Block’s size is fixed.
I’m not 100% sure this would be the right way to go but my best guess is that this step should really be creating a new empty byte sequence for the accumulation steps. The ArrayBuffer would be created afterwards, the byte sequence now being the data argument for “create”.
(This algorithm seems like an outlier fortunately — I didn’t spot others written with an ArrayBuffer initialization happening before its intended length is actually known.)
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.
Right, I also forgot this one in the search-and-replace, thanks for catching that!
The second step was actually already there (it was creating an ArrayBuffer from this ArrayBuffer below this text), so I've just changed this to creating a byte sequence, as you suggested.
c734af0
to
46aefca
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.
This seems okay, but I think it's better to be explicit when creating objects. However, given that it's not completely settled in IDL that seems like a reasonable concern to overlook.
SHA: f42610e Reason: push, by twiss Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
For created objects,
this
's relevant realm is of interest, rather than its relevant global object.Also, link out to WebIDL's
this
definition instead of referencing it explicitly.Also, note that objects are created in the relevant realm of
this
by default, rather than mentioning it everywhere.And finally, refer to the "create an ArrayBuffer" algorithm of WebIDL, rather than constructing
ArrayBuffer
objects ourselves.Resolves #346.
Preview | Diff