Why was namespacing dropped?

[rwaldron]

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 pattern that's counter to its original goals.

I've been back through the generic sensor spec's issue history 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. 

• Agree on coarseness of frequency option #6
• Should sensors be singleton? #8
• Should sensor EventTarget be immediately available or should they be accessed through a promise? #9
• When there are multiple sensors of a given type, how do we identify which one to instantiate? #26

Then this all changed. 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

2. 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).

3. A list of available sensors can be easily produced programmatically:

   > Object.keys(sensors);
   [
     "Accelerometer",
     "Gyroscope",
     "Magnetometer"
   ]

4. 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), on the single global object, named Sensors or sensors.

[anssiko]

Thanks for the detailed issue. We'll have F2F next Monday and Tuesday, and we'll surely take this issue to the agenda: https://www.w3.org/2009/dap/wiki/LisbonF2F2016#Agenda

You're welcome to call in, although the timezone might not be the perfect fit. We could try to arrange the slots slightly to better accommodate remote participants if needed.

[anssiko]

(When I thumb type, I close issues accidentally. And introduce typos. Doh.)

[rwaldron]

You're welcome to call in, although the timezone might not be the perfect fit. We could try to arrange the slots slightly to better accommodate remote participants if needed.

I don't want to disrupt the schedule so close to the actual meeting—but I would like to address this issue. How flexible is the present time, or even: how can I be the least inconvenient and the most respectful to other members' time?

(When I thumb type, I close issues accidentally. And introduce typos. Doh.)

Same here ;)

[anssiko]

We could take this issue as the last one on Monday 19 Sep around 12:30 UTC+00:00. Would that work for you?

We'll include call in details to the wiki ahead the meeting.

[marcoscaceres]

WebIDL now supports namespaces, so you could get a real "sensors" namespace... however, I'm not sure why WebIDL namespaces are currently limited to operations (and don't seem to allow attributes, which would serve as the constructors)? @domenic, is something funky about the API design here?

As currently proposed (using Sensors.whatevs) in the OP, the constructors would be statics on the Sensor interface, which is not really what we want IMO. I think we want @rwaldron's design of, for example:

const acc = new sensors.Accelerometer();

[domenic]

In general we didn't see any advantage in sprinkling dots everywhere. I.e. XSensor is better (fits with existing practice, etc.) vs. sensors.X.

[riju]

@rwaldron : Regarding point 3. A list of available sensors can be easily produced programmatically ..

Presence of say AmbientLightSensor in Object.keys(sensors), does not mean the system has a AmbientLightSensor, it means the browser simply has bindings for AmbientLight sensor. We need to make a sync call like start() to find out if the underlying platform actually has a sensor.

Also with Android API level 24, there is a concept of dynamic sensor callback which is used for receiving notifications from the SensorManager when dynamic sensors are connected or disconnected.

Do you want proposed global object sensor object to hold only available sensors for that platform ?
Does that mean we need to update the sensor object every time a sensor's connection state changes ?

I understand the "grouping related classes under a namespace" reasoning, but cannot see benefits beyond that.

[tobie]

@rwaldron:

The main problem here, outside of preferences expressed by different folks on this thread, is that there's no way to express this in WebIDL. The newly added namespace (arguably a misnomer) doesn't let us do that either (it can't contain constructors).

As a side note, there is no plan to call Accelerometer, AccelerometerSensor. It should just be Accelerometer (see Extensibility section on naming).

While I hear your concerns about the lack of namespacing, I do also have some concerns about namespacing:

1. it's inconsistent with the rest of the platform,
2. it might delay shipping the spec and implementation for years (or at least until we get ES6 modules in the browser),
3. the benefits are essentially cosmetic.

I'd be much more inclined to have a conversation around this if we had a clearer path as to what it would imply time-wise, in relationship to ES6 modules, and in WebIDL terms to namespace concrete sensors. It would be good to hear back from implementors on this topic and it would be super useful to know if there were other parts of the platform being worked on right now that would adopt a similar design.

[rwaldron]

@tobie according to @marcoscaceres, namespaces are now supported.

• http://heycam.github.io/webidl/#idl-namespaces
• https://github.com/heycam/webidl/pull/121/files

---

@domenic

In general we didn't see any advantage in sprinkling dots everywhere. I.e. XSensor is better (fits with existing practice, etc.) vs. sensors.X.

This isn't a compelling (or even substantive) argument in a runtime that supports destructuring:

const { Accelerometer, Gyroscope } = sensors;
// no more "sprinkled" dots. 

---

@riju

I understand the "grouping related classes under a namespace" reasoning, but cannot see benefits beyond that.

That is the point I consider to be the most important.

---

Sorry I was unable to attend any meeting or call, I had a doctors appointment at 9:30 (UTC-04:00, presently) which was an hour away by car.

[tobie]

@rwaldron:

@tobie according to @marcoscaceres, namespaces are now supported.

See my comment above:

"The newly added namespace (arguably a misnomer) doesn't let us do that either (it can't contain constructors)."

See also whatwg/webidl#177.

[rwaldron]

Oh wow. Thanks for following up expeditiously

[tobie]

Proposed resolution: we can't namespace for now. We'll reconsider when it's more practical to do so.