Transfer result interface constructors not defined or called properly

[yume-chan]

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

webusb/index.bs

Lines 1319 to 1323 in 7d7fab1

	interface USBInTransferResult {
	constructor(USBTransferStatus status, optional DataView? data);
	readonly attribute DataView? data;
	readonly attribute USBTransferStatus status;
	};

But steps in controlTransferIn says:

webusb/index.bs

Line 1046 in 7d7fab1

1. Let |result| be a new {{USBInTransferResult}}.

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

webusb/index.bs

Lines 1051 to 1053 in 7d7fab1

	1. If |device| responded by stalling the
	<a>default control pipe</a> set
	<code>|result|.{{USBInTransferResult/status}}</code> to {{"stall"}}.

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]

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]

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]

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.