Will fallback to a slow path disincentivize changing IDL constructs?

WebAssembly / interface-types

Other

641 stars 57 forks source link

Will fallback to a slow path disincentivize changing IDL constructs? #27

Closed annevk closed 5 years ago

annevk commented 5 years ago

A potential issue that occurred to me is that if a specification decides to change the signature of a method to enable new functionality or clean up some prose by making use of new IDL functionality implementations might not be eager to make these changes anymore as they could result in significant performance regressions on important sites.

It wasn't entirely clear to me whether this was considered.

jgravelle-google commented 5 years ago

It was considered, but IIRC the original proposal was to hard-error on mismatching signatures instead of falling back to a slower path. My guess is that that would cause much more hesitancy than a performance cliff.

Are there better solutions?

annevk commented 5 years ago

I'm not sure. It's probably worth pointing this out somewhere and perhaps in time also include a warning in the IDL specification itself to familiarize it among those writing specifications. With the goal that folks take even more care than usual to what gets written down.

lukewagner commented 5 years ago

Good point. I think there is a way to address this:

There will be a spec predicate "does this imported function 'match' this Web IDL Binding?" that determines whether the fast or through-JS path is taken (it's subtly semantically visible, so testable).
This predicate could accept bindings that pass a subset of the imports' parameters when the extra parameters are marked optional (the semantics being to pass the default value).
The guidance is thus (if it isn't already, which I bet it is), if you extend a method, make sure the new parameters are marked "optional".

This does require specializing a binding's generated stub to the callee, but I've been assuming that that is generally necessary in my mental model of the implementation, for a variety of reasons.

littledan commented 5 years ago

This outline seems plausible, but this does not sound like a trivial relation to specify (and I imagine the implementation side would be even more complicated). About whether this is expressive enough: seems like this would catch cases like adding an entry to an enum in the browser but not the application code, but not rephrasing checks from spec prose to IDL (e.g., https://github.com/WebAssembly/spec/pull/977). cc @Ms2ger.

lukewagner commented 5 years ago

I agree the relation will be complicated, but I think that is just inherent to the design, addressing not just this, but all the other bullets under Question #2 in the explainer that we discussed earlier.

Adding cases to enums or optional fields to dictionaries should independently fall out of the "structural subtyping" aspect of the design (mentioned in the Web IDL Types section of the explainer) of how value types are passed.

pchickey commented 5 years ago

Closing as out-of-date: the proposal no longer has the same sort of relationship to WebIDL as it did during this discussion. I don't think most of these concerns apply anymore. If I am incorrect, please re-open :)