-
Notifications
You must be signed in to change notification settings - Fork 166
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
alloc ArrayBuffers in correct global #377
Conversation
This looks right to me, but I'm way out of my depth here. jyasskin or bzbarsky would be much more appropriate reviewers, though Github won't let me @ mention them or add them to the review here. Perhaps @jcjones can do a more informed review. |
Indeed, I also attempted to add them to the reviewers list. @jyasskin should be able to be so added now that he is a formal member of the working group, but it may rely on having "write perms" to the repo (?)... |
Given this comment #293 (comment) over on issue #293 -- might we get @jyasskin and/or @bzbarsky review of this PR and if it's OK then we merge it? thx :) |
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 looks like it accurately implements Boris's suggestions. I also double-checked that you associated all object creations with a global, and I think you did. The ClientData creations that you didn't modify are all just used inside their algorithms and not returned to JS, so they're fine.
I think it's a bit overkill, and that we should wait to insist that new specs follow this style until core specs like Fetch and HTML update, but I don't object to the improvement.
Thanks for the review @jyasskin
I'm not sure I understand -- did you mean to say "...that we should wait on insisting that new specs follow this style because updates to core specs like Fetch and HTML may obviate it..." ? in any case, we've merged this and it's just a few detail-level things that ought to be updatable to whatever emerges in Fetch & HTML. thx again. |
@equalsJeffH No, I'm complaining at @bzbarsky. If the core web specs haven't updated even partially to a new style, we shouldn't be asking more peripheral specs like this one to update yet. There's no problem with this one updating; it's just work you didn't need to do yet. |
I guess from my point of view it's easier to make improvements in stuff that's being created than it is to refactor existing things. But yes, I agree we need to fix the existing things... The other part of this, honestly, is that I am quite confident that fetch and HTML will continue to be edited, so they will get updated. I have much less confidence in that for other specs, especially ones the W3C owns. Witness the recent dissolution of the webcrypto working group and the responses to questions about who will maintain the specs which more or less came down to "good luck with that" as far as I can tell. :( |
..fixes #293, see #293 (comment)