How to polyfill this proposal in JS? about interface-types

[jgravelle-google]

I'd been operating under the assumption that we didn't need to make sure this was polyfillable today with JS APIs, just that it would be polyfillable with JS before landing. The core issue I think is one of "today".

My model had been, "using JS APIs that require no more dependencies than the proposal itself requires." So, given that the proposal has a dependency on multi-value and anyref, a JS polyfill can assume multi-value and anyref.

I think that's a reasonable way to limit the design of the feature itself; @lukewagner has said we don't want to add any capabilities that are impossible without this proposal, and a good way to validate that is to have a JS polyfill. That implies though that the JS polyfill would have access to the same set of dependencies of the proposal itself.

I'm not sure that such a polyfill is the most useful thing for developers to build against though. Another goal for a polyfill is to have something we can build against today, to get users before we have the fully-realized proposal.

Phrased this way I think a strategy is clear: two polyfills with separate goals. One to validate and iterate on the design, and one for real users. One implemented with JS APIs, and wasm-bindgen (or some similarly-intrusive tool).

Another strategy, I think that you were implying, is to challenge the assumption that we don't want to introduce new functionality here. I don't have as solid a picture in my of head of why that needs to be true, aside from giving a simpler mental model of what this proposal is and what it does. By not adding new functionality we're able to clearly define this proposal as being about ergonomics and performance, doing things we already could, but more conveniently, portably, and efficiently.
Note that even with those limitations, I think the ergo+perf wins are sufficiently interesting. Are there interesting things we're leaving off the table by restricting ourselves to a polyfillable design?

[fgmccabe]

Well I thought that is did not actually have multivalues

On Fri, Aug 16, 2019 at 5:13 PM Jacob Gravelle ***@***.***> wrote: I'd been operating under the assumption that we didn't need to make sure this was polyfillable today with JS APIs, just that it would be polyfillable with JS before landing. The core issue I think is one of "today". My model had been, "using JS APIs that require no more dependencies than the proposal itself requires." So, given that the proposal has a dependency on multi-value and anyref, a JS polyfill can assume multi-value and anyref. I think that's a reasonable way to limit the design of the feature itself; @lukewagner <https://github.com/lukewagner> has said we don't want to add any capabilities that are impossible without this proposal, and a good way to validate that is to have a JS polyfill. That implies though that the JS polyfill would have access to the same set of dependencies of the proposal itself. I'm not sure that such a polyfill is the most useful thing for developers to build against though. Another goal for a polyfill is to have something we can build against *today*, to get users before we have the fully-realized proposal. Phrased this way I think a strategy is clear: two polyfills with separate goals. One to validate and iterate on the design, and one for real users. One implemented with JS APIs, and wasm-bindgen (or some similarly-intrusive tool). Another strategy, I think that you were implying, is to challenge the assumption that we don't want to introduce new functionality here. I don't have as solid a picture in my of head of why that needs to be true, aside from giving a simpler mental model of what this proposal is and what it does. By not adding new functionality we're able to clearly define this proposal as being about ergonomics and performance, doing things we already could, but more conveniently, portably, and efficiently. Note that even with those limitations, I think the ergo+perf wins are sufficiently interesting. Are there interesting things we're leaving off the table by restricting ourselves to a polyfillable design? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQAXUAHCBRKU24RTTRZOJTQE47CJANCNFSM4IMIRWAA> .

-- Francis McCabe SWE

[alexcrichton]

@jgravelle-google ah yeah those are some good points! This can also be construed as a question in terms of when we expect the polyfill to work, where a polyfill working today necessitates intrusive changes but a polyfill "tomorrow" means that the current design constraints fit nicely (e.g. using strings instead of indices).

FWIW I don't have a ton of experience with new web standards so this may be the case already (assuming that a polyfill isn't necessarily useful from day one but eventually the polyfill can be run), but the framing you mentioned of having two polyfills for both now and later seems pretty reasonable to me! I think it makes sense in that case to go ahead and design for the future polyfill rather than a today polyfill.

Are there interesting things we're leaving off the table by restricting ourselves to a polyfillable design?

AFAIK the strings-vs-indices is the only one so far, but it in theory could have large-ish ramifications if we start having something like a string subsection for interning. Otherwise though it's probably just something good to keep an eye out for!