WICG / webusb

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

Clarify wording on object equality #241

Open RReverser opened 11 months ago

RReverser commented 11 months ago

Is USBDevice equality guaranteed between different calls to getDevices() or requestDevice(), assuming that given device wasn't disconnected in between?

I assume it has to be - and, indeed, in the current implementation it seems so - otherwise things like comparing device from ondisconnect event with the stored instance also wouldn't work, but the spec only uses loose wording like

Add the USBDevice object representing device to devices.

which could also mean that implementation might be returning a collection of new USBDevices for each getDevices() call.

If it is indeed guaranteed, it should be reflected in the spec.

nondebug commented 11 months ago

Yes, object equality is guaranteed.

I think this is already guaranteed by the spec, but it could be made more explicit. The spec describes how to create "a new USBDevice object representing a connected USB device". These steps are only run "When a USB device is connected and detected" so it should only run once per connected device.

We use the same "the USBDevice object representing device" language whenever we need to return a USBDevice object (getDevices, requestDevice, connect/disconnect events). The spec doesn't say "new" here so I read it as referring to the object that was previously created when the device was first detected.

For WebHID I defined an internal slot navigator.hid.[[devices]] to hold HIDDevice objects for available HID interfaces. Perhaps we can adopt similar language to make it clearer how the USBDevice objects for available devices are created and stored.

RReverser commented 11 months ago

The spec doesn't say "new" here so I read it as referring to the object that was previously created when the device was first detected.

Yeah it doesn't say "new" but between

The UA MAY cache the result of the first enumeration it performs

and

Add the USBDevice object representing device to devices.

it's easy to misread this combination as if enumerated devices might be not cached and, correspondingly, that devices will be discovered anew and, correspondingly, wrapped into new USBDevice whenever you call getDevices.

I'm glad to hear it's guaranteed as this will simplify some code I have, just saying the spec wording could be more explicit here in that case.