Re: [sensors] Don't allocate response objects to avoid triggering GC

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