New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch from WebIDL arrays to FrozenArray<>s in the IDLs. #62
Conversation
@bzbarsky @domenic @luser @toji et al: please take a look. I left out any bits saying 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. |
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. |
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 |
I wasn't sure if this was actually needed or not. If we want that to be true just like it should be for |
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<T> and clarify in prose that some attributes should be cached by the user agent until new values have to be returned. Fixes w3c#28.
2e5de9c
to
924f782
Compare
Please see https://w3ctag.github.io/design-principles/#attributes-like-data third bullet point. |
Thanks, that's very helpful :) |
Sync our IDL file with w3c/gamepad#62 ("Switch from WebIDL arrays to FrozenArray<>s in the IDLs"). WebIDL has not had array types since 2015, so finally make our IDL files compliant with modern WebIDL following the spec fix. It is important to note that this change modifies the existing behavior slightly. - |axes| and |buttons| are now frozen objects with all the related consequences for its properties and prototype. - Those two attributes now return the same _object_ until their values change instead of always returning a new object on access. Doing so aligns our code with both the spec as well as Gecko, which has done the above ever since it implemented the Gamepad spec. Bug: 740875 Change-Id: Ifb618c9d4f8860eb55efc882e701dae7390808a5 Reviewed-on: https://chromium-review.googlesource.com/595979 Reviewed-by: Matt Reynolds <mattreynolds@chromium.org> Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com> Cr-Commit-Position: refs/heads/master@{#491440}
Follow-up to w3c/gamepad#62, which switched Gamepad#axes and Gamepad#buttons to FrozenArray<>s.
Follow-up to w3c/gamepad#62, which switched Gamepad#axes and Gamepad#buttons to FrozenArray<>s.
Follow-up to w3c/gamepad#62, which switched Gamepad#axes and Gamepad#buttons to FrozenArray<>s.
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.