W3C home > Mailing lists > Public > public-device-apis-log@w3.org > September 2016

[sensors] LaughometerSensor vs Laughometer?

From: Rick Waldron via GitHub <sysbot+gh@w3.org>
Date: Tue, 13 Sep 2016 18:28:27 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-176714534-1473791305-sysbot+gh@w3.org>
rwaldron has just created a new issue for 

== LaughometerSensor vs Laughometer? ==
This appears across all of the new sensor APIs, so while I limit 
comments to this repo, any resolution will apply to all relevant 

**The Generic Sensor spec describes a 
[naming](https://w3c.github.io/sensors/#naming) pattern that's counter
 to its original goals.**

I've been back through the [generic sensor spec's issue 
history](https://github.com/w3c/sensors/issues/) and cannot find an 
exact point in time that we diverged from one of the important points 
of the original proposal: All newly specified sensor classes should be
 defined under a single global identifier "namespace". This was 
specifically called out as part of the problem that existing sensor 
specs designs created: they were piling identifiers onto the 
global/window object. 


(For that exact case ^^^ these new spec are actually worse, since you 
can only see one at a time)

Where the following illustrates a superior view showing a set of 
related classes: 



During all of the early conversations, in all of the example code and 
use cases, we made sure to write such things as: 

let accelerometer = new Sensors.Accelerometer(); 
// or sometimes as: 
let accelerometer = new sensors.Accelerometer(); 
// ...either is better. 

- https://github.com/w3c/sensors/issues/6
- https://github.com/w3c/sensors/issues/8
- https://github.com/w3c/sensors/issues/9
- https://github.com/w3c/sensors/issues/26

[Then this all 
 Unfortunately, I didn't have a chance to review that specific change 
at the time (admittedly, there was a period last year where I was 
swamped day-to-day and was unable review every change). [A look at the
 issues filed for that time period show that there wasn't discussion 
about the 
 .  If I had seen the change, I promise that I would've argued against
 it and would've absolutely died on that hill. 

Here are some of the arguments I would've made and stand by 

1. Only a single `Sensors` or `sensors` global is created
1. When defined as property of an object that's appropriately named, 
ie. `Sensors` or `sensors`, it's clear to all readers of that source 
code that all things defined there are going to be a sensor, or 
relevant to sensors—so their own names don't have to explicitly 
include the word "Sensor". This point may be seen as partially 
subjective, but I think that most would agree that when naming an 
accelerometer (or whatever) class, that `Accelerometer` is better than
 `AccelerometerSensor`. (There is presently 4 years of empirical 
evidence supporting the last statement).
1. A list of available sensors can be easily produced 
  > Object.keys(sensors);

2. Class names can be "shorthand" aliased via destructuring: 
  let { Accelerometer, Gyroscope } = Sensors;
  let a = new Accelerometer();
  let g = new Gyroscope();


## Proposal

- The Generic Sensor specification should define a single global 
object, named `Sensors` or `sensors`. 
- The Generic Sensor specification should mandate that all sensor 
classes are defined as the value of a property, whose name is the 
sensor of which is represented (eg. `Accelerometer`), of the single 
global object, named `Sensors` or `sensors`. 

Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/127 using your GitHub account
Received on Tuesday, 13 September 2016 18:28:35 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:52 UTC