Closed rakuco closed 6 years ago
@bzbarsky @domenic @luser @toji et al: please take a look.
I left out any bits saying Gamepad#axes
should be cached because they're just doubles, but I'm OK with adding that if you think it makes more sense.
I'd also appreciate it if the people implementing the spec could also chime in and say if it makes sense to cache these values (and whether they do change) at all -- I'm coming to this from a WebIDL and bindings perspective.
I left out any bits saying
Gamepad#axes
should be cached because they're just doubles
The array entries are doubles, but the actual thing returned is an Array object and it being cached or not is quite observable, no? It needs similar language too.
The array entries are doubles, but the actual thing returned is an Array object and it being cached or not is quite observable, no?
Yes. My comment was more on the lines of whether it actually made sense to cache the Array at all or not (and avoid converting the same array to JS every time).
I'm not sure what you mean by "whether it actually made sense to cache the Array". You want gamepad.axes === gamepad.axes
to be true, right? So some caching needs to happen somewhere.
You want
gamepad.axes === gamepad.axes
to be true, right?
I wasn't sure if this was actually needed or not. If we want that to be true just like it should be for buttons
and hapticActuators
, then yes. I'll update the PR with a version that makes all 3 properties cached.
I wasn't sure if this was actually needed or not.
Please see https://w3ctag.github.io/design-principles/#attributes-like-data third bullet point.
Please see https://w3ctag.github.io/design-principles/#attributes-like-data third bullet point.
Thanks, that's very helpful :)
Arrays have not existed in the WebIDL spec since 2015, so the Gamepad spec (as well as the accompanying Gamepad Extensions one) were providing invalid IDL definitions.
Switch to FrozenArray and clarify in prose that some attributes should be
cached by the user agent until new values have to be returned.
Fixes #28.