[sensors] LaughometerSensor vs Laughometer?

rwaldron has just created a new issue for 
https://github.com/w3c/sensors:

== 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 
specs.

**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. 

![](https://i.gyazo.com/0270bec2e3486d743ec996fe7eea0b7a.png)

(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: 

![](https://i.gyazo.com/6d8f956f8c99d74e17a8bd25c400a4af.png)

---------------------


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


```js
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 
changed](https://github.com/w3c/sensors/commit/367428429dc9d0e86128515b15a6ef969351a7fe).
 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 
change)[https://github.com/w3c/sensors/issues?page=3&q=&utf8=%E2%9C%93]
 .  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 
to-the-day:

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 
programmatically: 
  ```js
  > Object.keys(sensors);
  [
    "Accelerometer",
    "Gyroscope",
    "Magnetometer"
  ]
  ```

2. Class names can be "shorthand" aliased via destructuring: 
  ```js
  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