search

WICG / webusb

Connecting hardware to the web.
https://wicg.github.io/webusb/
Other
1.3k stars 126 forks source link

Transfer result interface constructors not defined or called properly #207

Open yume-chan opened 2 years ago

yume-chan commented 2 years ago

Today I found that USBInTransferResult is actually a constructor on window, that looks strange, who would want to new a USBInTransferResult?

Also, it's defined as

https://github.com/WICG/webusb/blob/7d7fab135e96556bd27da8db04cb23a34c74139f/index.bs#L1319-L1323

But steps in controlTransferIn says:

https://github.com/WICG/webusb/blob/7d7fab135e96556bd27da8db04cb23a34c74139f/index.bs#L1046

USBInTransferResult's constructor has parameters, but here it's not specified?

https://github.com/WICG/webusb/blob/7d7fab135e96556bd27da8db04cb23a34c74139f/index.bs#L1051-L1053

USBInTransferResult.status is a read only attribute, is it allowed to write it?

Earlier today I was reading WebCodecs spec, there many return types are dictionaries, with optional members, but in the steps they are definitely assigned. What's the general guideline for using interfaces or dictionaries as return types?

reillyeon commented 2 years ago

If I were doing this today I would have specified all of the transfer result interfaces as dictionaries instead because that makes them easier to work with. Since this is shipping in browsers it's not worth trying to change it now. It only adds a little overhead.

The places which construct a USBInTransferResult should be calling the constructor with the arguments rather than setting the read-only attributes directly (they can't technically be set, since they are read-only). In the constructor the parameters should be used to initialize internal slots which are then returned by the accessor steps for the read-only attributes.

If you don't mind I'll re-purpose this issue for tracking the clean-up work to define and use the constructors properly.

yume-chan commented 2 years ago

I understand they can't be changed now, and of course you can re-purpose this issue for that.

For my last question, my understanding is that inferfaces map to JavaScript classes, and dictionary-ies are plain JavaScript objects. For these return values with no behavior (methods), dictionaries should be used because plain objects are slightly faster. Is that right?

reillyeon commented 2 years ago

I'm not familiar with the particular performance characteristics of interfaces vs. dictionaries in different Javascript implementations. In both specification language and Blink/V8 it is significantly simpler to work with a dictionary than an interface.