- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Mon, 08 Sep 2014 19:56:02 +1000
- To: Rick Waldron <waldron.rick@gmail.com>, Tim Volodine <timvolodine@google.com>
- Cc: Tobie Langel <tobie.langel@gmail.com>, Marcos Caceres <marcos@marcosc.com>, Jonas Sicking <jonas@sicking.cc>, public-device-apis@w3.org, Anssi Kostiainen <anssi.kostiainen@intel.com>, "public-script-coord" <public-script-coord@w3.org>, Doug Turner <dougt@mozilla.com>, Domenic Denicola <domenic@domenicdenicola.com>, Anne van Kesteren <annevk@annevk.nl>
On Mon, 8 Sep 2014, at 19:40, Mounir Lamouri wrote:
> I think the main difference between the two approaches is here: you
> create the sensor object synchronously then set the value asynchronously
> while Tim creates the object asynchronously, thus never expose an
> undefined value. I think Tim's approach is better because having
> undefined value would be fairly hard to handle for the developer. An
> alternative would be to not expose a synchronous getter but instead do
> something like:
> ```
> var sensor = new Sensor({ [...] });
> sensor.getValue().then(function(value) {
> [...]
> });
> ```
> but that comes with the downside of requiring developers to keep track
> of the current value themselves if they want to have a synchronous
> access to it.
(There was confusion on IRC on whether I was supporting this proposal
above. I'm not.)
I think the proposal above would be better than having sensor.value
sometimes returning null because it would at least be consistent as far
as web developers are concerned. However, there is no direct synchronous
access to the value.
I think Tim's proposal is less elegant (ie. getDeviceOrientationSensor()
is less elegant than new DeviceOrientationSensor()) but it solves all
the requirements: it is an asynchronous API that is easy to use for
developers because after it is initialized, they have direct access to
the value.
I would consider the cosmetic issue less important than developer
friendliness.
-- Mounir
Received on Monday, 8 September 2014 09:56:28 UTC