{"action":"opened","issue":{"url":"https://api.github.com/repos/w3c/sensors/issues/127","repository_url":"https://api.github.com/repos/w3c/sensors","labels_url":"https://api.github.com/repos/w3c/sensors/issues/127/labels{/name}","comments_url":"https://api.github.com/repos/w3c/sensors/issues/127/comments","events_url":"https://api.github.com/repos/w3c/sensors/issues/127/events","html_url":"https://github.com/w3c/sensors/issues/127","id":176714534,"number":127,"title":"LaughometerSensor vs Laughometer?","user":{"login":"rwaldron","id":27985,"avatar_url":"https://avatars.githubusercontent.com/u/27985?v=3","gravatar_id":"","url":"https://api.github.com/users/rwaldron","html_url":"https://github.com/rwaldron","followers_url":"https://api.github.com/users/rwaldron/followers","following_url":"https://api.github.com/users/rwaldron/following{/other_user}","gists_url":"https://api.github.com/users/rwaldron/gists{/gist_id}","starred_url":"https://api.github.com/users/rwaldron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rwaldron/subscriptions","organizations_url":"https://api.github.com/users/rwaldron/orgs","repos_url":"https://api.github.com/users/rwaldron/repos","events_url":"https://api.github.com/users/rwaldron/events{/privacy}","received_events_url":"https://api.github.com/users/rwaldron/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-13T18:28:25Z","updated_at":"2016-09-13T18:28:25Z","closed_at":null,"body":"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.\r\n\r\n**The Generic Sensor spec describes a [naming](https://w3c.github.io/sensors/#naming) pattern that's counter to its original goals.**\r\n\r\nI'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. \r\n\r\n![](https://i.gyazo.com/0270bec2e3486d743ec996fe7eea0b7a.png)\r\n\r\n(For that exact case ^^^ these new spec are actually worse, since you can only see one at a time)\r\n\r\nWhere the following illustrates a superior view showing a set of related classes: \r\n\r\n![](https://i.gyazo.com/6d8f956f8c99d74e17a8bd25c400a4af.png)\r\n\r\n---------------------\r\n\r\n\r\nDuring all of the early conversations, in all of the example code and use cases, we made sure to write such things as: \r\n\r\n\r\n```js\r\nlet accelerometer = new Sensors.Accelerometer(); \r\n// or sometimes as: \r\nlet accelerometer = new sensors.Accelerometer(); \r\n// ...either is better. \r\n```\r\n\r\n- https://github.com/w3c/sensors/issues/6\r\n- https://github.com/w3c/sensors/issues/8\r\n- https://github.com/w3c/sensors/issues/9\r\n- https://github.com/w3c/sensors/issues/26\r\n\r\n\r\n[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. \r\n\r\nHere are some of the arguments I would've made and stand by to-the-day:\r\n\r\n1. Only a single `Sensors` or `sensors` global is created\r\n1. 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).\r\n1. A list of available sensors can be easily produced programmatically: \r\n  ```js\r\n  > Object.keys(sensors);\r\n  [\r\n    \"Accelerometer\",\r\n    \"Gyroscope\",\r\n    \"Magnetometer\"\r\n  ]\r\n  ```\r\n\r\n2. Class names can be \"shorthand\" aliased via destructuring: \r\n  ```js\r\n  let { Accelerometer, Gyroscope } = Sensors;\r\n  let a = new Accelerometer();\r\n  let g = new Gyroscope();\r\n  ```\r\n\r\n\r\n-------------------------\r\n\r\n## Proposal\r\n\r\n\r\n- The Generic Sensor specification should define a single global object, named `Sensors` or `sensors`. \r\n- 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`. \r\n\r\n\r\n"}}
{"actor":{"display_login":"rwaldron"}}