- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Dec 2016 11:51:26 +0000
- To: public-device-apis-log@w3.org
The original API design as proposed by @rwaldron didn't have GC collection issues. The new design does, mainly because I wanted the same API to be available from the event object and the sensor instance itself. Now that we've stopped exposing the sensor reading from the event object, maybe we should reconsider exposing it as a separate object on the sensor itself to avoid GC issues. What if we tried something like that instead (here for gyroscope)?: ```webidl [SecureContext] interface Sensor : EventTarget { readonly attribute SensorState state; readonly attribute DOMHighResTimeStamp timestamp; void start(); void stop(); attribute EventHandler onchange; attribute EventHandler onactivate; attribute EventHandler onerror; }; dictionary SensorOptions { double? frequency; }; [Constructor(SensorOptions options)] interface Gyroscope : Sensor { serializer = { x, y, z, timestamp }; // so we can still get a reading object when needed readonly attribute unrestricted double? x; readonly attribute unrestricted double? y; readonly attribute unrestricted double? z; }; ``` That would allow uses like this: ```js let gyro = new Gyroscope({ frequency: 240 }); gyro.start(); gyro.onchange = _ => { console.log("Rotation rate around the X-axis " + gyro.x); console.log("Rotation rate around the Y-axis " + gyro.y); console.log("Rotation rate around the Z-axis " + gyro.z); }; gyro.onerror = event => console.log(event.error.name, event.error.message) ``` Thoughts? -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/153#issuecomment-265131404 using your GitHub account
Received on Tuesday, 6 December 2016 11:51:39 UTC