Re: [sensors] Discrete vs continuous reporting modes

> I see... the main question is still how to expose it. So when you 
create a sensor, you already know how it is implemented, and there are
 constraints on what reporting policies can be set.

Yes.

> In simplest approach setting a policy (e.g. "continuous") would fail
 for some of the sensors.

Yes.

> The implementation needs to know what are the allowed values, so the
 list of allowed policies should be provided during construction.

That seems overly complex. What are the use cases for this in 
practice?

> So in subclassing vs parametrizing I would be still in favor of the 
latter: instead of creating an instance of a DiscreteSensor, we could 
create a generic Sensor with more limited data reporting capabilities 
(given to the constructor). This is simpler both to implement and use.

I'm not sure what this changes for the API consumers. In both cases, 
they will be instantiating a `AmbientLightSensor` object. They don't 
really need to care about the content of the prototype chain tbh.

I'm not sure I understand the implementor benefit.

I do feel this is clearer to spec (and most importantly to extend).

> The problem I see with the classification approach is that it's too 
much tied to a current policy of hardcoding behavior;

Unfortunately, I don't understand what you mean by this a "a current 
policy of hardcoding behavior." :(

> it may also create confusion that some sensors are sometimes 
DiscreteSensors but in other deployments they could be 
ContinuousSensor.

Yes. So that's where I believe the potential problem is. But I'm not 
sure whether or not this is actually an issue in practice (that is, 
are sensors behaving in incompatible ways across platforms).

> Nit: the names are not intuitive to people who don't know this 
particular problem. One may think discrete refers to digital, and 
continuous to analog.

Agreed. This needs better terminology.

> Also, differentiation between ```onchange``` and ```ondata``` 
shouldn't be misused for handling this issue. AFAIK usually 
```onchange``` is used when a property of the object has changed, and 
```ondata``` would be the proper event for handling data. The spec is 
not clear about this, and the examples see to use ```onchange``` where
 ```ondata``` would seem more appropriate.

Well, given the sensor values are exposed on the sensor themselves, 
this doesn't seem to be such an issue.


-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/75#issuecomment-172824791 using 
your GitHub account

Received on Tuesday, 19 January 2016 11:36:35 UTC