Francis McCabe

It is not really within the remit to support all JS features. As far as wasm is concerned; calling a constructor is indistinguishable from calling a function; (think calling a...

I believe that we only need two elements: an ‘interface type’ similar to that in webidl and an ‘invoke method’ adapter instruction. On Tue, Nov 26, 2019 at 10:53 AM...

Actually I think not. Type imports as far as I understand them are used to introduce opaque types. This is kind of the opposite: the interface says what you can...

This is interesting. I am ok with leaving it to be post ‘minimum awesome product’ . The rationale for its eventual inclusion has to be whether having an object notion...

Not sure I like either the automatic approach nor the special annotations. OO patterns are pretty ubiquitous in API design; which, to me, suggests that we honor this properly. (The...

approximately, yes. There are going to be times when the interface is more important than the type; and vice versa. I believe that the correct modeling is 'hasa' rather than...

Jumping in with both feet ... :) It seems to me that regardless of usage, importing a module (whether it is JS or Wasm) should simply be subject to the...

instead of stack ops like dup, swap etc we are proposing the use of let: effectively a temporary local. This is part of the function reference types proposal https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md

I don't know what WIT folk are planning. But, they will likely follow what goes on in Interface Types on this kind of issue.

WIT is a sub-proposal which is part of WASI. Not really the same as Interface Types; although there is a somewhat close connection :)