How to handle JS methods/constructors?

[alexcrichton]

One feature of this proposal that may have gotten lost in the shuffle from the previous "WebIDL Bindings" moniker to interface types is the ability to configure how JS functions are invoked. Some imported functions want to be invoked as a new function (e.g. new Function(...)) and others want to be invoked as a method where the first argument is the this of the call (e.g. foo.bar(other, arguments)).

In reviewing this again, I'm not sure if we have an avenue of introducing this with adapter functions? You sort of want to annotate that an adapter import is calling the imported function in a particular way, but this is very much a JS-ism that isn't really present in most other languages (methods, maybe, constructors, less so).

Do others have ideas of how we might reincorporate this JS feature back into the proposal? The only goal here is to hook up wasm/C++ engines directly without JS glue in the middle, so I don't think it really matters how we do it so long as the end goal is met for methods/constructors/etc.

[devsnek]

Here are the two "primitive" procedures you'd have to support:

• Call(F, thisValue, args)
• Construct(F, newTarget, args) (newTarget is a constructor, usually F)

Even if you combine them somehow into a "JS calling convention": F(thisValue, newTarget, ..args), and make sure you are only passing thisValue or newTarget, you still have to decide somewhere to either perform a Call or a Construct, you just move it up the chain.

[fgmccabe]

This is not forgotten. We currently have instructions for calling a function and for invoking a method.

On Fri, Nov 22, 2019 at 2:49 PM Gus Caplan ***@***.***> wrote: Here are the two "canonical" procedures you'd have to support: - Call(F, thisValue, args) - Construct(F, newTarget, args) (newTarget is a nullable constructor) Even if you combine them somehow into a "JS calling convention": F(thisValue, newTarget, ..args), and make sure you are only passing thisValue or newTarget, you still have to decide somewhere to either perform a Call or a Construct, you just move it up the chain. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#87?email_source=notifications&email_token=AAQAXUHYBLBRSGWDAE3MVV3QVBOYDA5CNFSM4JQWWYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7C3WI#issuecomment-557723097>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQAXUCIEH7M5WFI6WQETG3QVBOYDANCNFSM4JQWWYGQ> .

-- Francis McCabe SWE

[devsnek]

Yeah, the problem isn't methods, it's construct. A construct is not a call, it just sometimes looks like a call (in fact you can do new Bar, without parentheses or arguments)

[fgmccabe]

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 factory method in Java). There are two halves to each adapted function: an internal import adapter and an external export adapter. If the external adapter chooses to invoke a constructor that seems a reasonable strategy to me.

On Sun, Nov 24, 2019 at 12:54 PM Gus Caplan ***@***.***> wrote: Yeah, the problem isn't methods, it's construct. A construct is not a call, it just sometimes looks like a call (in fact you can do new Bar, without parentheses or arguments) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#87?email_source=notifications&email_token=AAQAXUCRXCAWX6KBIHTUFTDQVLSXJA5CNFSM4JQWWYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAUTZQ#issuecomment-557926886>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQAXUDKU5LLVAP3B6MOBADQVLSXJANCNFSM4JQWWYGQ> .

-- Francis McCabe SWE

[lukewagner]

I think the distinction between (static) functions and methods belongs on the interface-typed function signature. This distinction wouldn't have any meaning when both sides were wasm: the arguments simply get passed as normal. It's only when one side is non-wasm that the distinction might become meaningful for determining how to interpret the call for that other language.

In particular, when a function's type was "method", a JS caller would know to pass the receiver as the first argument (shifting the actual args right by one), instead of ignoring it, and a JS callee would know to pass the first argument as the receiver (shifting the other actual args left by one), instead of passing undefined. Other dynamic languages should be able to have a similar interpretation, I think.

There's also the question of whether we really need to have a "constructor" distinction. If we wanted total JS co-expressivity, we would (and we'd need an explicit newTarget argument too), but I don't think that's a hard requirement. We do want efficient Web IDL calls, but, while Web IDL constructor functions are required to be called via new, that's in the ECMAScript binding; the WebAssembly binding can simply not make that requirement (and pass the default newTarget if there's any question about that). If we're calling a non-Web-IDL JS function, then we're calling JS anyway, so having to use a generated JS glue function isn't that bad. So I think that means we're fine without "constructor".

[alexcrichton]

I think I may have missed the method-related instructions perhaps? I don't think they're currently in the repository, so to confirm are they either in PRs or in people's heads so far? Or is there documentation I'm missing?

I would also tend to agree that we can probably skip JS constructors until we hear otherwise. They're not necessarily the hot path we need to optimize for WebIDL integration.

[lukewagner]

I don't currently see a need for a method-related instruction; just a "method" flag on interface function signatures.

[fgmccabe]

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 Luke Wagner ***@***.***> wrote: I don't currently see a need for a method-related instruction; just a "method" flag on interface function signatures. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#87?email_source=notifications&email_token=AAQAXUEZE4YMBNMQVSRVISTQVVA6BA5CNFSM4JQWWYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFGPWIA#issuecomment-558693152>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQAXUHRY7E5K5MDNUJOPRTQVVA6BANCNFSM4JQWWYGQ> .

-- Francis McCabe SWE

[lukewagner]

Oh right, now I remember this idea. So what would a value of an interface interface type be lifted from and lowered into? Is the abstract interface value semantically a record containing an abstract type and a bunch of closures? Does this introduce a dependency on the type imports proposal?

[fgmccabe]

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 do with the type. Some languages (such as java) have a concept of method which is effectively an inseparable set of functions and instance variables. JS does not have this really but it is implied by the way webidl is written. One can rationalize this in terms of the related functionality; JS does not honor the inseparability aspect of it but it is ‘a thing’ when you want to model APIs

On Tue, Nov 26, 2019 at 12:56 PM Luke Wagner ***@***.***> wrote: Oh right, now I remember this idea. So what would a value of an interface interface type be lifted from and lowered into? Is the abstract interface value semantically a record containing an abstract type and a bunch of closures? Does this introduce a dependency on the type imports proposal <https://github.com/WebAssembly/proposal-type-imports/blob/master/proposals/type-imports/Overview.md> ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#87?email_source=notifications&email_token=AAQAXUEKHUVT4YJ6JHDIXG3QVVPL5A5CNFSM4JQWWYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFG44SI#issuecomment-558747209>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQAXUARGAUOBWS3SRJVZ4LQVVPL5ANCNFSM4JQWWYGQ> .

-- Francis McCabe SWE

[lukewagner]

Ok, but what core values do you lift/lower an interface value from/to?

[lukewagner]

Actually, let me rewind and revise my earlier position; I actually think we don't need any new interface types or adapter instructions to be able to effectively and efficiently call Web API methods.

The reasoning is basically the same as I gave above for why we don't need a "constructor" flag. In particular, since, as part of this overall proposal, we're defining a new "WebAssembly binding" in the Web IDL spec, we can simply say that, when the callee is a Web IDL method (as indicated by it being inside a Web IDL interface and not being marked static or a constructor), the receiver is taken as the first wasm argument (unconditionally). And conversely for when the host calls wasm through Web IDL.

This is backwards compatible because all existing calls today necessarily go through the Web IDL ECMAScript binding (and must continue to do so for backcompat reasons); only (new) adapted import calls can go through the new Web IDL WebAssembly binding.

I also think this is still polyfillable b/c if I want to polyfill Web API function f in JS, I know whether f is a method or a static function and so I can simply take all the wasm arguments (passed to my polyfill) and use them to call f appropriately.

The only use cases we lose are allowing wasm to call or be called by JS while directly passing a receiver. But, as already reasoned above, if we're calling to/from JS anyway, it's no big perf deal to use a little JS glue (which we are often using anyways, for other reasons).

FWIW, if we do want to pursue an interface interface type like @fgmccabe is talking about (probably renaming the type to avoid requiring typography to disambiguate "interface" ;), then I think it could serve as the basis for expressing idiomatic OO interfaces in JS et al without wrappers. But I think that's all post-MVP and we can meet our stated MVP Web API perf goals without them, using only the above approach.

[fgmccabe]

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 should be there or not. That in turn depends on whether it is important in modeling API designers’ intentions.

[alexcrichton]

I'm personally a bit lost in how this is expected to work, but it sounds like y'all have this in hand. I suspect this would also be clarified pretty quickly once we get closer to having spec text being written. If y'all are ok seems fine to close this since it sounds like it's expected to all still be handled reasonably enough!

[lukewagner]

Actually, @ajklein pointed out a faulty assumption in my logic above (perhaps the same thing tripping up @alexcrichton): I was assuming that, when calling JS, the JS is catered to the wasm caller. But in the "JS polyfill" case (in which someone has monkeypatched the global prototype chain, or something analogous in import-maps world), the JS polyfill is being used for both JS and wasm callers, so it's actually expecting the receiver as the receiver, not the first argument.