RE: Ambient light API redesign

I like Rick's proposal especially from a theoretical level since it has constructors, whereas the async-acquisition proposal does not. But I see your point about the initial `undefined` value. If you'll indulge a bit of musing...

It's not that I think constructors are an inherent good, or even that developers love them. But, they are important for rationalizing the platform's JS interface. With that in mind, how do we rationalize the async-acquisition version?

It's interesting, because unlike many constructor-less APIs, there is no browser-only magic in the async-acquisition API. It simply ensures that the sensor is constructed with an initial value. That is, you could envision it being implemented as:

```js
navigator.getDeviceOrientationSensor = options => {
  var sensor = new DeviceOrientationSensor(options);
  return DeviceOrientationSensor.requestValue().then(v => {
    sensor.value = v;
    return sensor;
  });
};
```

Alternately, if you don't like `sensor.value` being writable (why not?) you could envision it as

```js
navigator.deviceOrientation.getSensor = options => {
  return navigator.deviceOrientation.getCurrentValue().then(v => {
    return new DeviceOrientationSensor(Object.assign({ value: v }, options));
  });
};
```

What's interesting is that, keeping in mind the why-constructors mindset I point out above, you don't even have to expose the constructor on the global scope, if you think it is a bad developer-facing interface. All I ask is that it exist, such that we have a rational explanation for instances of DeviceOrientationSensor being created.

Received on Monday, 8 September 2014 09:57:34 UTC