Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarify structured clone behavior for WebAssembly objects. #1074
Sounds good to me. We usually call these kind of things "monkey patches". It would be good to file an issue upstream (against HTML at least) to make them aware of this. Having said that, this again somewhat depends on your strategy. If you do go with IDL you don't need to change HTML. IDL objects are more extensible than objects that are defined using more primitive means.
referenced this pull request
Jul 18, 2017
annevk@ Unsure on the whether WebIDL makes more sense for the Web embedding, JS.md likely needs this notation to match up with the ES spec. Will talk more to domenic next week on notation preferences. Mainly trying to narrow what's currently here (as before the PR it just says structured clone).
@flagxor based on the discussion in #1048 it's my understanding that eventually these objects need to be exposed inside wasm (Wasm?) as well. It's also my understanding that there will be a wasm bindings for Web IDL. It would therefore be much "cheaper" to define these in IDL (and also provide a more consistent API from the eventual wasm side of things).
And as a lesser concern, it matters for how we organize the specifications. If you define these without IDL we'll need to define the serialization/deserialization in HTML, but if you define them with IDL you can define everything in the wasm standard (or wasm API standard or whatever it is).
Although I think it's good to have a discussion about IDL vs. not, I think this PR can proceed without resolving that. This PR does an admiral job of formalizing the semantics of structured serialization, which is sorely needed. It provides a precise specification implementations can use to get interoperable behavior. The spec structuring (IDL vs. not) can be fixed later, without changing any observable behavior.
Now, to continue the review efforts...
LGTM, only two nits left. Please feel free to merge after fixing instead of going through another round-trip :).
A few more questions and nits, but still seems mergeable from my perspective. I'm not sure I fully understand all the memory instance stuff though.